ERP 2.50:Developers Guide/Concepts/Multi-Language and Translations
Contents |
Introduction
Openbravo ERP is a multi language application. It can be translated to different languages and then it is possible to select one of these languages to show the user interface in that language.
Structure
Openbravo ERP manages multiple languages defining those languages and maintaining the translated texts in translation tables in database, the two sections below explain how this structure is.
Languages
Languages are defined in AD_Language table, which can be accessed from within the General Setup || Application || Language menu.
This table maintains a list of all languages and indicates which of them are currently in use. A language is in use in case it is marked as System Language.
Openbravo has out of the box a number of predefined languages, but it is also possible to define new ones. As AD_Language table is not exported directly to modules, if a new language is defined it must be exported to a module as reference data.
TRL Tables
Translated texts are maintained in TRL database tables. Each table with data that requires translation has an associated TRL table. Note that apart from the translations defined in core it is also possible to define new translation tables for new tables in modules.
Structure
TRL tables are named like the base table to be translated plus a _TRL suffix. Thus the table where translations for AD_Window table are stored in is AD_Window_TRL.
These are the columns that a TRL table must have:
- Standard columns: ID, Client, Organization and audit columns.
- Foreign key to base table: for example in AD_Window_TRL there is a AD_Window_ID column that links the the record in AD_Window to be translated.
- AD_Language column. This column indicates the language this record translates to.
- IsTranslated column. It is a boolean value (Y/N) that indicates whether the record is translated or not. See population section for more details.
- Translation columns. For each column in the base table to be translated, the TRL table has a column with the same name. For example the name column in AD_Window table is translatable so AD_Window_TRL table has a name column.
Link between TRL and base tables
TRL tables are linked to their base tables by naming: each TRL table is named like its base one plus the TRL prefix and each translated column has the same name.
Additionally, the columns in the base table that require translation must be checked as translation.
Population
TRL tables are automatically populated by database triggers. When a new record is added to the base table a trigger for that table should add a new record to the TRL table copying to the translation column the original ones and setting the isTranslated column to 'N'. If the base record is updated, the record in the TRL table must be updated setting the isTranslated column to 'N' but maintaining the translation columns as they were, this indicates that translation should be manually reviewed.
Here is an example of this kind of triggers.
Manual UI
Translation for manual windows and reports requires to pay special attention. It basically works in the same way as standard TRL tables, in this case the base table is AD_TextInterfaces and its translations table is AD_TextInterfaces_Trl.
These tables are populated when the system is built as part of the complete process or the can be populated explicitly invoking directly the translate ant task.
This task parses all files that can be translated (html, jrxml, srpt and fo) looking for translatable tags. When they are found, it checks whether the text in that tag exists in AD_TextInterfaces and if it does not it is inserted and a copy is done in AD_TextInterfaces_Trl for the rest of active languages.
Note that this table has a FileName column. When looking for the existence of the text it is done for all records that have the same file name as the one where the tag is found and in those that do not have any file name. This is used to allow to share the same translation for all tags with the same text regardless the file they are in, but it also allows to have one of these generic translations (without file name) but to translate a tag with that text in a different way for a singular file.
Before a compile complete is done, AD_TextInterfaces.IsUsed column is set to 'N' for all records of modules in development and when the text is found is set to 'Y' again. After the process finishes, this table is cleaned up removing all unused entries. All of this is executed by the compile.complete task in case tr property is true.
 | After modifying any Manual UI template is highly recommended to run compile.complete to maintain AD_TextInterfaces in sync with actual files. |
Modules and languages
Module's language
When a module is defined, in case it contains elements that are translatable (for example windows, manual html pages, reports, etc.) it is necessary to check the Translation Required field and to select a language.
This selected language sets the base language for the module. This means that records for this module in base tables will have all the texts in that language and the TRL ones will contain translations for the rest of active languages. For example if we define a module's language as Spanish and this module adds new windows, these windows will be named in Spanish and they could be translated (in the TRL tables) to English.
Translation modules
A module can be set as a Translation module, in this case it will only contain a translation for another module. For more information read the article.
Translations
Although translations can be done using directly the application the standard process consists in exporting the translation to XMl files and translating them. Here is a complete explanation for this process.
What is new
These are the new features in r2.50 related to multi-language and translations.
On line translations
In previous releases, after installing a language or modifying a translation label, it was necessary to rebuild the system to visualize this modification. It was necessary because there was a copy for each interface object (html, jrxml...) for each system language in src-loc directory.
From r2.50 translations are generated on-line without creating a physical file copy for each language. This means that it is possible to install new languages or modify translation labels and use them directly, without rebuilding the system or relogin.
Full right to left support
Openbravo ERP r2.50 supports right to left languages. To define a language as right to left just check the RTL Language box in the Language definition window. Further information about how to develop a skin taking into account this new RTL feature, in the Customizing Openbravo article
Translation modules
With modularity it is possible to define translation modules. They facilitate the language installation process hiding all complexity. To install a language now is enough with installing the module, and a process will automatically executed which will set that language as system language, populate trl tables and load translations.
| Languages: |
ERP 2.50:Developers Guide/Concepts/Multi-Client and Multi-Org | ERP 2.50:Developers Guide/Concepts/Multi-Currency