View source | View content page | Page history | Printable version   

Projects:Translation Management/Language Handling Refactoring


Language Handling ReEngineering



This document has arisen from new requirements for handling Module Installation in relation to the Modularity project.

In Openbravo 2.40.x and earlier ones English (US) is the base language for all Openbravo ERP UI strings, all of them registered in the Application Dictionary. It means that every entry in the Application Dictionary needs to be defined in English (US). To get that entry in other language it's needed to translate it through the TRL tables.

The basic concept is to allow module developers to create new modules in languages other than English (US). This has a flow on effect through the application in the handling of languages and the presentation of the user interface.


The intention of this work is to provide improved handling for languages and to move to a language agnostic application. To achieve this there is to be no differentiation between English (US) and other languages used in the application. Instead this will be replaced with 'development' language with the core marked as using English (US), and allowing Module developers to create new modules in languages other than English (US) and for the processes within the application to handle the new schema of translations to get strings in the user language and linking them to the user interface.

The new concept is that module owners will be allowed to freely define the base language for their modules instead of being forced to choose English (US). All application dictionary entries will be defined in that language. Openbravo core will continue using English (US) as its base language.


This document covers the conceptual implementation and relevant snippets relating to its implementation. This work will be combined with the current Translation Management project to provide implementation guidelines for each step of the redesigned process.

Functional Requirements

Native Language Module Development


With the implementation of Modularity the aim is for a module developer to be able to create the module in the language of their choosing. In doing this there will be instances where the module does not contain an English(US) version of text strings used in the presentation of the user interface. Therefore it will be necessary for the module to contain an attribute that defines the native language of the module and for the translation management process in the application to handle this in a manner that enables the correct presentation of the user interface.


Language Agnostic Application

The translation management project will be required to treat the application in a 'language agnostic' manner. In this respect the module owner will need to be able to define their own base language.

Exporting and Importing Translations

With the implementation of modularity there is a need to alter the handling of locating and placing language exports. The following folder tree is proposed for implementation in 2.50.

The generation of the language folders and the files within them will be dependant on whether that language is defined as System Language within the instance.


It is very important that the new implementation does not effect the performance of the application and should not increase any lag in response times.


  1. Modify WAD to enable labels to be tagged and referenced through the XML file.
  2. Update XMLEngine to populate the label tags in the xml files with dynamic label texts.
  3. Update WAD to dynamically replace TextInterfaces in manual user interface artifacts with label tags.
    • This process of dynamically generating the user interface will work on the following premises:
      1. Core is to be treated as a module with English as the base language.
      2. Modules will be defined with a base language.
      3. Translation process will continue to populate translation tables with complete text data for all artifacts.
  4. Review Synchronize Terminology process to ensure correct function.
  5. Review translation database processes to ensure correct function.
  6. Create test plan and implement for modules and module translations.
  7. Provide implementation for storing xml files in the database.
    • Including handling for module id.
  8. Provide implementation for exporting text strings to xml files as defined in the folder architecture.
    • Export process will include generating folders for modules contained within the exported elements.
    • Export process will only use default locations for storing exported xml files.
  9. Provide the means to copy the base language into another language/country installation.
  10. Provide the means to retrieve language packs from the repository or install from a local file source.
  11. When generating a user interface artifact the application will check if the language elements are in the trl tables.


Workflow Diagrams

Module Installation Process

Retrieved from ""

This page has been accessed 5,638 times. This page was last modified on 8 June 2012, at 05:31. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.