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

Projects:Translation Management/Technical Documentation



This document outlines the technical specification for the first phase of the implementation of the improved Translation Management process. The scope for this document is outlined below.


The technical specification contained herein is defined to create the base functionality for translation management in Openbravo ERP. This base implementation will be built on and extended in the remaining two iterations of this project.

The main goal here is to provide a methodology and framework for implementation which is as modular and independent in relation to the varying contexts of the solution. All touch points between the different context areas should be through a single access point and dependencies should be as minimal as possible.


TRL1 - Language Creation/Definition

TRL2 - Source existing translations

TRL4 - Importing a New System Language

TRL5 - Enable a New System Language

OTRL1 - Translation Repository

NTRL3 - Translating Files

Ubiquitous Language

Technical Implementation





Context Diagram


Openbravo ERP

Communication Layer




Creation and Definition of a Language

This is perhaps the most work in the rewrite of this process, given that there is a new level of automation to the saving and creation of the language while removing other aspects of the current process to make the whole process more intuitive and simpler.

Source Existing Translations

Initial Language Import Implementation

Import to Database

The existing process of importing translation files into the application takes care of populating the database with the relevant entries, this includes populating the AD_TEXTINTERFACES_TRL table. Therefore there is nothing to then stop us dynamically calling the translated text from the database without compiling. Proposal is that this process will not be changed dramatically in function as it fulfills requirements for providing the data required to dynamically populate the web pages.

Enable A New Translation


Currently within a WAD generated window the meta-data for a label field is as follows

<td class="TitleCell" id="IsActive_lbl_td">
  <SPAN class="LabelText" id="IsActive_lbl">ActiveĀ </SPAN>

The aim is to provide a simple implementation that will enable the XMLEngine to dynamically interpret the users current language to configure the html complete with translated text.


Currently within the XML document for each page there are the following entries for each field

<FIELD id="IsActive" boolean="checked" withId="paramCheck">IsActive</FIELD>

with the language passed to the document through

<FIELD id="AD_Language" attribute="value">AD_Language</FIELD>

Page Generation Implementation

WAD Generated Windows

Using the combination of Field Id and the Label Id we can dynamically populate the label value. The id for the label should be the same as the id for the field but with _lbl suffixed at the end of the id. This allows access to the required labels without having to provide additional information in the XML document or change the schema for the HTML document.

Sourcing the translation

The following query can be used to identify translations for labels within the WAD generated windows.

WHERE like 'Request User' --where 'Request Folder' is the text in the label field.
	OR element.columnname like 'RequestUser' -- where 'RequestUser' is the field id value in the xml file

the where clause can use wither the labelid with the suffixed '_lbl' removed or the field id from the XML document. Field id value would simplify the process.

Manually Created Windows

Sourcing the translation

The following query can be used to identify translations for labels within manually created HTML files.

select inter.*, interTRL.*
where inter.text like '%Format file%'
	AND (inter.filename like '/org/openbravo/erpCommon/ad_forms/FileImport.html' OR inter.filename is null)

Need to provide contingency to provide default text for any values that have not been translated.

Translation Repository Implementation

The repository will be accessed through a communications layer in the form of a web services implementation. This implementation will store information regarding the location of the repository, the list of relevant files contained in the repository, and information regarding the status of the translation.

The communications layer is responsible for receiving the request from the application to locate a translation and then return the relevant status information based on the search object.

The user will then make a selection from this list and this request will pass to the communications layer to package the appropriate files and return them to the requestor where they can be unpacked and installed by the application.

For this phase their is no requirement to be able to write information from an application directly to the repository. The repository is to be read-only for requests from the application/installation.

A convenient means for the repository administrator to update the repository information is to be decided.

To avoid duplication of effort and excessive development time it is preferable to reuse existing implementations of this type that already exist within the Openbravo server architecture. Can this be linked in with the heartbeat server??

Translating Files Implementation


Appendix A. UML Diagrams

Translation Util library

TranslationUtils class diagram

Retrieved from ""

This page has been accessed 8,628 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.