View source | Discuss this page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Add page
Show collection (0 pages)
Collections help


Translation Engine Concepts


About this document

In this document we will explain the way translations are handled by Openbravo, giving special focus to the file structure to store the translations and how Modularity affects the translation process. The article gives the necessary background to understand the Openbravo's translation engine and it is recommended to read it before starting any translation effort.

Remember that this document is written from a theoretical perspective. If you just want to start translating without knowing the underneath details of the Openbravo translation engine, you can safely go to the How to Create and Update Translation Modules document.


Openbravo is a software that supports translations from the very beginning. Everything related to the User Interface can be translated: Windows, Tabs, Fields, Labels, Reports, Menu entries, Messages, Descriptions, Helps, etc. And even Masterdata can also be translated, like Country or Currency names. That means the full ERP is ready to be translated.

Translations are distributed inside a set of XML files with a simple structure. Each XML file represents an Application Dictionary table that can be translated; this kind of tables always have a _TRL suffix (see Multi-Language and Translations - TRL_Tables for more info).

The XML files are included into the corresponding translation module and make it easier for the user to install them into any Openbravo instance.

Modularity and Translations

Since 2.50 version, Openbravo supports the concept of module that extends the base ERP functionality. That usually means these modules add new User Interface elements which need to be translated, like for example messages, labels or menu entries. We can identify this kind of modules because they have the Translation Required flag set to Yes inside its module's definition, that represents they can be translated.

LocGuide translation concept 10.png

The translation of any module is done through another module containing its translation files for the desire language and that depends on the original one (see How to create and update translation modules – Create a translation module for details).

So what it's important to understand is that, in a modular environment, it is necessary to translate all the modules included in our instance to have a fully translated ERP, which means creating a translation module for each original module which has the Translation Required flag set to Yes.

XML translation file structure

The structure of the XML translation files in Openbravo, which is based in the Compiere's one, is as follows:

The following piece of code is an example for the AD_ELEMENT_TRL table translated into Spanish (Spain):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<compiereTrl baseLanguage="en_US" language="es_ES" table="AD_ELEMENT" version="">
  <row id="0131585AC1F246DBAF6B84E53534F5FA" trl="Y">
    <value column="Name" isTrl="Y" original="Accounting Schema Currency Credit">Moneda del Esquema Contable para el Haber</value>
    <value column="PrintName" isTrl="Y" original="Accounting Schema Currency Credit">Moneda del Esquema Contable para el Haber</value>
    <value column="Description" isTrl="Y" original="The amount credited to an account, converted to the organization default currency.">El importe abonado (haber) a una cuenta convertido a la moneda por defecto de la organización.</value>
    <value column="Help" isTrl="Y" original="The Account Credit Amount indicates the transaction amount converted to this organization's accounting currency">Refleja el importe de la transacción (haber) convertido a la moneda del esquema contable de la organización</value>
    <value column="PO_Description" isTrl="N" original=""/>
    <value column="PO_Help" isTrl="N" original=""/>
    <value column="PO_Name" isTrl="N" original=""/>
    <value column="PO_PrintName" isTrl="N" original=""/>

As you can imagine, this XML files are automatically generated by Openbravo, so you don't need to manually create them, but just translating the value tag as we have seen in the example.

Set of translation files

The Export Translations process is in charge of creating the Openbravo's XML translation files. Each file represents an Application Dictionary table related to the User Interface and, therefore, contains strings which can be translated. The name of each XML file has the following structure: <table name>_TRL_<ISO language>_<ISO country>.xml. Example AD_ELEMENT_TRL_es_ES.xml that contains the translation into Spanish (Spain) for the AD_ELEMENT table.

In order to create a high quality translation, it is very important to understand the kind of information stored in each table/file. Here is the list of tables involved into the translation in alphabetical order:

LocGuide translation concept 20.png

LocGuide translation concept 30.png

LocGuide translation concept 40.png

LocGuide translation concept 50.png

The previous list corresponds to the translation tables included into the Openbravo 3 distribution. Take into account that any module can extend the list of tables to be translated. In this case the export translation process will automatically create the new necessary XML files to be translated.

Populating translation tables

When the user installs a translation module, the ERP reads the translation XML files inside the referencedata/translation/<language ISO code>_<country ISO code> and imports all the translated strings to its corresponding _TRL table of the database. In case of using the Import translation process, the XML are read from the attachments/lang/<language ISO code>_<country ISO code>/<java package name> folder of your instance. Both ways can be used for importing translations.

Inside the Application Dictionary, the user can afterward check the imported translation at its respective table, having the possibility to even modify the translated strings and to export the updated XML files again through the Export translation process.

For example, imagine we have forgotten to translate a concrete message. As System Administrator role, we can open the Message window and search for the original message. Inside the Translation tab, which is associated with the AD_MESSAGE_TRL table, we will find the translation for this message. We can safely modify it and export the translation again.

LocGuide translation concept 60.png

Retrieved from ""

This page has been accessed 4,305 times. This page was last modified on 15 June 2012, at 12:57. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.