• Table*: when the table to register physically exists in the database, this will be the physical name of the database. If it were a virtual table, its name is at the user's discretion. Usually, the criterion to follow is to define a generic table for those alias fields that are generic for the entire application, and for those that are specific to a specific area of the application, a specific virtual table is defined for that area. In any case, it would be convenient for these virtual tables to have a common pattern in terms of their coding, since this would facilitate their location and identification.

  REMARK

  It should be borne in mind that if the system detects in the table name some character of the type: ¡!""#$%&'`´()*+,-.¨·/:;<=>¿?^@|\\[{} , the system will replace it with a _ (underline), since these characters are not supported as valid for the name of a table.

• Language*: language in which they are expressed, both descriptions and information regarding the table. When the system connection users are defined through the configuration database (wic_conf), among other data, the language in which the application is to be used and operated is indicated. Depending on the user and language indicated, you will use the information in the tables corresponding to that language.
• Verified: it specifies whether an expert or translator has checked the text. Never mind the current status, there is no automatic process that will affect it.
• Tag name: short description.
• Description: normal description of the table, that will be the one usually reflected in the help of the application.
• General data: this will be where the meaning and properties of the table will be described in detail in terms of their functionalities, relationships, specifications, etc. This information is important for the application users in the sense of being able to know in depth the possibilities of each table, as well as the aspects to consider in each one of them. Therefore, the more explicit this information is, the more facilities will be granted to the user to know and understand the application.

• Table: name of the table to which the column belongs, that must be previously defined in the table dictionary for the same language in which you want to express the column information.

  REMARK

  It should be borne in mind that when the system detects in the column name some character of the type: ¡!""#$%&'`´()*+,-.¨·/:;<=>¿?^@|\\[{} , the system will replace it with an _ (underline) , since these characters are not accepted as valid for the name of a column.

• Language: language in which they are expressed, both descriptions and information regarding the column. When the system connection users are defined through the configuration database ( wic_conf ), among other data, the language in which the application will be used and managed is indicated. Depending on the user and language indicated, you will use the information in the columns corresponding to that language.
• Verified: It specifies whether the text has been checked by an expert or translator. Never mind the current status, no automatic process will affect it.
• Country:
• XSQL expression: this check box must be activated when you want to enter XSQL code as a label. This code must be reported in the Label field. This way, when you use the column in a form, then you get the result label of executing an SQL query, for example.
• Column*: when the column to register physically exists in the database, this will be the physical name of the database. If it is a column of a virtual table, its name must be the one specified in the definition of the objects in which it will be used.

  REMARK

  It should be borne in mind that when the system detects in the column name some character of the type: ¡!""#$%&'`´()*+,-.¨·/:;<=>¿?^@|\\[{}, the system will replace it with an _ (underline), since these characters are not accepted as valid for the name of a column.

• Label: this mnemonic description of the column represents a type of abbreviated description, which will be the one that is presented as a title in all those objects in which it is found as a column or output field. If it is necessary to put a line break, for example, if the tag contains more than one word and a line break is desired, it is only supported for it.
  
  

  Expression Evaluation
  Example	Description
  <xsql-text><eval-date d='-1'>$FECINI</eval-date></xsql-text>	The label <xsql-text> allows the evaluation of XSQL expressions at runtime, producing the corresponding code according to the database engine. Access the programming documentation XSQL Script to expand the information.
  (select coment from cejercic where numero = $ejerci-1)	Simple SQL statement whose syntax is common to all engines.
  DATE($fecfin)+$diacad	SQL function common to all engines.

• Description: Description of the column, which is very important because it will be reflected by the system, among others, in the following cases:
  • Help . On all automatic online help pages generated by the system.
  • Comment . In those objects of type transactional it will function as a comment of the fields that the object contains.
  • Information . When a HTML page of the result of an object is obtained, it is used as additional information to the title of the columns that the object contains.
• General data: This will be where the meaning and properties of the column will be described in detail in terms of their functionalities, relationships, specifications, etc. This information is important for application user in the sense of being able to know in depth the possibilities of each column, as well as the aspects to consider in each of them. Therefore, the more explicit this information is, the more facilities will be granted to the user when it comes to understanding and knowing the application.

Through this option you can access the definition of includes or lists. These can be assigned as possible values to the columns, through the parameterization of their attributes, or to the object query variables. From this option, if the user has the necessary permissions, they can create, delete or modify these definitions.

An include is used by assigning it as attribute of a column so that it is a reusable object. You could also assign includes as possible values of a query variable associated with an object.

The system loads the dictionary includes for the user's language. The includes that do not depend on the language (for example, an include of type SELECT that obtains the company codes of the application) are registered only once.

To identify the column options, following data is required:

• Code*: name of the include. It is recommended to adopt a coding criteria and methodology in order to reuse the includes in all those fields of the database that are functionally equivalent.
• Value*: value of the data. The value of the data will depend on the type of include to be defined.
• Order*: order in which the system will present the list of defined values. This indicated order will be valid as long as the include is of type Check or List. Because if it is an include of Select types, the order will be the one established in the SQL statement reported, simply indicating here the value 0.
• Icon: adds an image to the included, for an easy identification of the selected option. See icon section.

Depending on how the column attribute to use the include is defined, and whether it specifies values or an SQL query, or if it has a reference column, different functionalities can be obtained. More specifically, we can have column attributes with the following types of include:

• None (no include)
• Checkbox
• Radio button
• Select one
• Select multiple

• For the same code, multiple records that specify the different values and their descriptions are stored.
• A single record for the include code specifying value 'SELECT' and the corresponding query.
• Include with value 'SELECT' specifying reference column and dynamic condition.

Icon to be displayed to the left of the column value if the condition (expression) is met or there is no display condition. The icon image must be saved in Images of the Object SQL.

The expression is written in javascript format. For example:

'#locale'=='es'

'#locale'=='es' && '#tabname'!='mytable'

It may be necessary to obtain the values from the include list of a table in the database, in this case you must indicate in this field the SQL statement to perform the SQL Query or the call to an XSQL-Script.

This query is possible to be written in XML grammar.

SELECT codigo, nomsis FROM csistema ORDER BY codigo

Only when a query SQL statement is used to obtain the available data from the include, it is possible to report the "Default value for the SQL query" field.

There is also the possibility of obtaining the data by making a call to an XSQL-Script. The XSQL-Scripthas to return a ResultSet or virtual table. An array can be converted to ResultSet using the <array.toResultSet> function.

<call>
<![CDATA[
<xsql-script>
<body>
  <return>
     <array.toResultSet>
        <system.user.getDatabases xdict='$DBMS' />
     </array.toResultSet>
   </return>
</body>
</xsql-script>
]]>
</call>

If the include is a SELECT to the database, it will show as a result the list of the values obtained when making the query. This field indicates the value that should appear selected in the list.

This default value is obtained through this SQL query. The query must return a single record with a single field. It can be written in XML grammar. The default value of the column attributes that have this include will not be considered, since it will be the value obtained through this query that prevails.

Example to get the default value:

<select>
    <columns><nvl>MIN(sistem), 'A'</nvl></columns>
    <from table='cdefcont' />
    <where>tabname = 'capuntes'</where>
</select>

The includes of type Check are those to use when the values to enter are of the type TRUE-FALSE or YES NO , which in the first case are stored in the database as 1 and 0 respectively and in the second as Y and N, depending on the field is a SMALLINT or a CHAR (1).

The checkbox will be activated for the first value of the include according to the order field, and deactivated for the second value.

The presentation of the Y value would be Activated, and for N Disabled.

The definition of an include of this type would be the following:

The includes of type List are those to be used when the values to be introduced are several and diverse, such as a field that indicates the status (open, closed, validated, accounted for ...).

An include of this type allows you to display a description that corresponds to the value Internal field in database. For example a field that indicates the state . It could be a char(1) . The correspondence of values could be:

• A: open
• C: closed
• V: validates
• B: accounted for

The form shows a list with the descriptions, which provide the necessary information to the user, but internally the value is managed by the character code ( char (1) ).

The definition of an include of this type would be the following:

Includes type List with SQL query are those that use an SQL query to obtain the data list. In this case no descriptions are reported and the value field indicates the keyword SELECT . Only in this case it is possible to report the default value for the SQL query, which is also obtained via an SQL query.

Both SQL statements (obtaining list of values and default value) can be written in XML.

The definition of an include of this type would be the following:

<select>
    <columns><nvl>MIN(sistem), 'A'</nvl></columns>
    <from table='cdefcont' />
    <where>tabname = 'capuntes'</where>
</select>
                                

Labels are small descriptions that allow idiomatic translations and can be easily reused.

This form allows defining labels in an idiomatic way. These labels can be used during form construction. Labels can be used in:

• Box headers in forms
• Form layouts
• Button titles
• Data validation messages
• Syntax Mnemonics
• Map layers
• Values of ranges

When the connection users to the system are defined through the configuration database ( wic_conf ), among other data, it is defined the language in which the application will be used and managed. The function getDictionaryLbl(String labelID) allows to obtain a label in the user's language of the user's connection to the system. Depending on the user and language indicated, the system will use the description of the labels corresponding to that language.

These are the fields that define a label:

• Language*: select a new language and use this language in Description and Information fields.
• Verified: it specifies whether the text has been checked by an expert or translator.
• Code*: identifier of the label. Repeat this code for each selected language in order to create a new language of the same label.
• Description*: this text will be shown to the user in the objects where labels have been used.
• Information: usually, the documentation implemented here is shown by a floating component or a large fixed component, so that the information can become very extensive, even in the form of a document with sections.

The mnemonic codes are used to identify the syntax applicable to a field. The use of Labels to describe the content of the mnemomic code allows it to be displayed in the user's configured language.

These are the fields that define a mnemonic:

• Code*: name that identifies the syntax mnemonic code.
• Label*: name of the label that will describe the mnemonic code, visible from the field this mnemotechnic is assigned to. When the users click on the label, the text of the information box defined in label form (if present) will be displayed by a floating component.
• Background color*: background color for the mnemonic label.
• Text color*: text color for the mnemonic label.

This is the repository of images that illustrates the dictionary (including menus) and the SQL objects. These images can be obtained by means of a file or from icons packaged into a font. Icons look like images, but they can be handled as fonts. Due to the color and scalability properties of fonts, it is highly recommended the use of icons rather than images.

These are the fields that define an image:

• Name*: code that identifies the image.
• Description: brief description of the icon/image.
• Source*: select between the three options depending on the origin of the image.
  • File: an image file.
  • Font "Awesome": Font Awesome is a huge collection of icons. Access the Font Awesome website and select the desired icon and copy the icon code.
  • Font "Material": Material Design Icon is a full suite of official material design icons, created and maintained by Google, for easy scalable vector graphics on websites or desktop. Access the Material Design Icon website and select the desired icon and copy the icon code.
• Glyph (hieroglyphic): when the source is a font, enter here icon code from the website.
• Color: when the source is a font, select here desired color for the icon.

  IMPORTANT

  If no color is selected, the system will display the icon in black or white depending on the darkness/lightness of the background.

• Choose file: when you select this option, standard opening dialog box appears and an image file can be selected. After unloading image, the fields Size, Type, Width and Height will be automatically filled in.

Through this option you can access the checks dictionary to enter the descriptions associated with the check constrains of a database catalog.

These descriptions will be those shown to users when they insert or modify records in a table, in case that the record to be inserted or modified does not meet the conditions of any of the existing checks.

Through this option you can access the check constraints register, of which it is desired that the system does not display or warn of possible problems when evaluating the syntax of these checks. The mere fact of registering a check is already sufficient condition so that it is not displayed.

However, registering it does not mean that it cancels its operability and functionality, since it will be its own database the one that denounces the cases in which the conditions of the same are not fulfilled.

To improve the consistency of the database, the location options allow you to find and/or modify the incomplete elements of the logical dictionary. It mostly refers to translation tables.

This procedure allows us to generate the logical tables (wic_jdic_tabdata) and columns (wic_jdic_coldata) dictionaries in the established language of the physical tables in the database that meet the query conditions.

This procedure is of great use when we start defining dictionaries according to the established database. This is because by analyzing its catalog of tables and columns, it generates all dictionary records of the catalog.

The process accesses the systables catalog of the indicated database and obtains the tables that meet the criteria:

• For each table, it checks if it has been created in the wic_jdic_tabdata logical dictionary for the indicated language. If not, the process generates it.
• For each table, it accesses the physical record of columns sycolumns to obtain the columns of the table.
• For each column it checks if it has been defined in wic_jdic_coldata . If not, the process generates it.
• Tables and/or columns that were already cataloged are ignored

This example shows that for the database named 'demo_form", it will be created the table name and columns names in French (if they don't already exists). The name and descriptions will coincide with the name defined in the physical dictionary.

Once the generating process has finished, the system will display a list of records inserted in the dictionaries.

This object allows editing translations in the column dictionary, showing two blocks of information with the texts of the two selected languages.

• In general, this resource will be used informing the reference language, usually spanish (es), in the source language and any language from the available list in the destination language.
• The source language and the target language cannot be the same.
• The target language cannot be the reference language.
• Changes may be applied, interchangeably and at the same time, in any of the texts of the two languages.
• The edition of a record will mark it as verified. This allows you to exercise some control over the work pending translation. Extended content columns (wic_jdic_coldata.col_info) do not apply control over the audit indicator.
• The edition in the reference language will deactivate all verification marks on the entries of the remaining languages. This allows alerting that perhaps your translations should be reviewed.

The content selection process allows discriminating the records on which we want to review or translate, according to:

• Review entries pending translation: only records that have never been translated will be selected. Records translated with the verification mark disabled will be excluded.
• Review entries pending translation and verification: records that have never been translated will be selected and also records with an verification mark disabled. This is the default selection method.
• Review everything: all records will be selected (not translated, translated and translated with verification mark disabled).

The modification process allows the management of repeated contents. For this purpose, the changes are made in two blocks according to:

• The modification process allows the management of repeated contents: for this purpose, the changes are made in two blocks according to:
  1. First proceed to modify the selected record in the three text columns: col_memo, col_desc and col_info. The records will be marked as verified.
  2. In the second phase, all records whose contents in columns col_memo and col_desc are coincident are modified, except for the modification on column col_info. The records will be marked as verified.
  3. In the third and final phase, all records whose contents in column col_memo are coincident are modified, except for the modification on columns col_desc and col_info. In this phase, only the repetitions in the column col_memo are considered. The records will not be marked as verificate, unless the base record on which we have applied the modification does not have content in the column col_desc: in that case the record will be marked as verified.
• Changes in target language texts: this block of modifications is substantially similar to the block of changes defined for the source language, but with the difference that the change guide to be applied are the records with matching texts in the source language. This cause that sometime the process requires inserts in the wic_jdic_tabdata and/or wic_jdic_coldata tables, for cases of records in the target language without translation.

This object allows the translations editing, regardless of the source language and/or the target language.

A source language and a target language must be selected, just like in column editing section. This object shows two blocks of information with the texts of the two selected languages. Remember that the edition on the reference language will deactivate the verification marks on the entries of the rest of languages for this label.

The content selection process allows discriminating the records on which we want to review or translate, according to:

1. Review entries pending translation: only records that have never been translated will be selected. Records translated with the verification mark disabled will be excluded.
2. Review entries pending translation and verification: records that have never been translated will be selected and also records with an verification mark disabled. This is the default selection method.
3. Review everything: all records will be selected, these are not translated, translated and translated with verification mark disabled.

Through this option you can access the definition of the idiomatic descriptions of column contents, where, if the user has the necessary permissions, you can create, delete or modify these definitions.

It allows applications to display the idiomatic content of certain contents (tables.columns) in the user's language. As a rule, they will be descriptions belonging to configuration and parameterization tables, such as the descriptions of the tax rate tables, methods of collection or payment, workflows, statements, etc.

The contents registered in the table of idiomatic contents of columns are the support for the translations (or substitutions) that the Axional Studio application servers will perform during the generation of HTML, PDF pages, etc.

To facilitate the offline translation and updating tasks of this table, optionally, it has a loading and unloading process based on the process of columns idiomatic content management.

This process allows the loading and/or downloading of contents through an Excel file to the wic_jdic_coltran idiomatic contents of columns . It is simply a help tool and its remit can be accomplished by any other manual or automatic procedure.

• Database: code of the ERP or client database that will facilitate the contents to be translated. The language of these contents is considered the base language of translation and it is implicit in its contents.
• Language: it is the resulting or target language to which we are going to translate, that is, if the base or reference language is Spanish and we want to translate into English, this will be the one we must indicate in this field.
• Action: Load or Unload, see below.
• Excel name: name of the Excel file.
• Pattern: Pattern in LIKE notation to determine the set of tables to process.

Unload: allows you to download the content of texts from the client's database to an Excel file document, which will serve as a working base for translation tasks. The tables for which content will be downloaded must be informed in the table wic_jdic_colattr column attributes table with the Translate flag enabled.

Process:

1. It gets the list of tables.columns for which you want to offer content translation according to the Translate indicator, mentioned above, and limited to the execution Pattern of this process.
2. It connects to the customer database that has been reported, downloads the contents and records them in a temporary table.
3. Add to the temporary table the possible contents already translated in previous loading and unloading processes, which will be obtained from the wic_jdic_coltran idiomatic column of contents.
4. Finally, all the information is downloaded in an Excel document, which can be used as a translation work base for later loading by this same object or any other procedure.

Load: allows you to load the contents of an Excel document on the table of wic_jdic_coltran
idiomatic contents of columns.
Process:

1. Removal of content on the wic_jdic_coltran table, according to:
   Copy

   <delete table='wic_jdic_coltran'>
                       <where>
                           wic_jdic_coltran.ref_dbms = <p_dbms/>       AND
                           wic_jdic_coltran.tab_name LIKE <p_pattern/> AND
                           wic_jdic_coltran.lang_dst = <p_lang/>
                       </where>
                   </delete>

2. It loads all the contents of the Excel document on the wic_jdic_coltran table.

Through this option you can access the description of the objects of the application, where, if the user have the necessary permissions, they can create, delete or modify these definitions.

Each object shows the definition of the title, the short description and the detailed information in the base language. It can also be defined in several languages (Spanish, Catalan, English, etc...). In this case, it can be modified directly from this form.

A term that is repeated throughout the application can be translated in different ways by each translator, something that can generate confusion and different interpretations in the reader. The lack of consistency becomes an even greater risk when it comes to a multilingual project.

The following tools facilitate the task of maintaining the linguistic coherence throughout the entire application.

This tool facilitates the quick search to find those entities that lack of language translations.

From a source language, this tool looks for the different entities that have no translation in the target language. The query options allows you to limit your search to certain entities among:

1. Panels (wic_jmnu_tab)
2. Menus (wic_jmnu_app)
3. Tables (wic_jdic_tabdata)
4. Columns (wic_jdic_coldata)
5. Includes (wic_jdic_include_locale)
6. Labels (wic_jdic_lbldata)
7. Check descriptions (wic_jdic_chkdata)
8. Objects (wic_jrep_object)
9. Channels (wic_pt_channel_int)
10. Headers (wic_jrep_colhdr)
11. Error codes for xsql_scripts (wic_xsql_script_messages)

This option allows to improve the quality of translations by comparing the same terms, which guarantees consistency in translations within a dictionary.

From a source language, this tools looks for the existing translation in two more selected languages. The query options allows you to limit your search to certain entities among:

1. Panels (wic_jmnu_tab)
2. Menus (wic_jmnu_app)
3. Tables (wic_jdic_tabdata)
4. Columns (wic_jdic_coldata)
5. Objects (wic_jrep_object_info)
6. Headers (wic_jrep_colhdr)
7. Labels (wic_jdic_lbldata)
8. Functional groups of objects and panels (wic_jrep_roles)
9. Includes (wic_jdic_include_locale)
10. Error codes of xsql_script (wic_xsql_script_messages)

This report performs a test (simulation) with the results of replacing sentences in dictionaries.

For example, suppose we want to replace in the dictionaries for the Portuguese language the text Aquisições with the text Compras, three automatic substitutions will be used anywhere in the text, according to:

1. The texts as they were introduced: Aquisiçõeswill be replaced by Compras.
2. Lowercase texts: aquisições will be replaced by compras.
3. Uppercase texts: AQUISIÇÕES will be replaced by COMPRAS.

Dictionaries analyzed

1. Panels (wic_jmnu_tab)
2. Menus (wic_jmnu_app)
3. Tables (wic_jdic_tabdata)
4. Columns (wic_jdic_coldata)
5. Objects (wic_jrep_object_info)
6. Headers (wic_jrep_colhdr)
7. Labels (wic_jdic_lbldata)
8. Includes (wic_jdic_include_locale)

Possible conflict with singular and plural words

Singular word substitutions can cause problems about their corresponding plural words. Let's take the following example:

A widespread error has been detected in Portuguese dictionaries, Local Office, in Portuguese was incorrectly translated by Delegaçõe.

By correcting this word Delegaçõe by Delegação words will be spoiled in the plural, changing Delegações by Delegaçãos. As the plural of Local Offices in Portuguese must be Delegações, we will have to apply a second substitution according to:

1. First substitution: Delegaçõe by Delegação. This substitution will alter the plural words by changing them from Delegações to Delegaçãos, that is, to correct it you will have to apply the second substitution.
2. Second substitution: Delegaçãos by Delegações

This object will execute a process for replacing one sentence with another in dictionaries. The way this replacement is performed is the same described in the previous section Test phrase replacement in dictionaries.

This process generates a complete dictionary of titles and descriptions of SQL objects in a given language. Entries generated are those which do not exist for that language compared to the central SQL object dictionary.

This process copies the language content of the active dictionary to the selected dictionary. It is required that the structures of the language location tables in both dictionaries are identical.