Projects/Translation Management/Language Handling Refactoring

Introduction

Overview

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.

Purpose

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.

Scope

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

ISSUE

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.

SOLUTION

• Attribute to be added to the module definition to show the native language.
• Strings within the module to be placed in the top level table relevant to the components of the module are in the native language of the module, irrespective of whether that language is English(US) or not.
• Translations for module interface elements will be placed in the TRL table for that element.
• The application to use the base language for a module as a pointer to the text for the field. The base language text will always be in the top level table, translations added for that module will be placed in the TRL table. Translations will be available for all System Languages in the instance other than the native language of the module of that element. It means that there could be translations for English (US) if the native language of the module is other than English (US) and English (US) is a System Language in the instance.
• New engine process used in the dynamic generation of the user interface which detects the users chosen language and checks for
  1. If the native language of the module is equal to the user language the strings will be taken from the main table.
  2. else the string will be taken from the user language entry in the trl table.

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.

• AppsOpenbravo
  • translation
    • Core
      • en_US
      • es_ES
    • Module 1
      • en_US
      • es_ES
    • Module 2
      • it_IT
    • ....

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.

Performance

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.

Deliverables

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.

Appendix

Workflow Diagrams

Module Installation Process