Log in / create account
Openbravo.com
Issues
Forge
University
View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Add category.
Show collection (0 pages)
Collections help

Search

Category:Localization Process

Languages: 

English | Translate this article...

Contents

Introduction

Localizations are very important for Openbravo ERP project and our community is doing a great effort creating and maintaining them and giving suggestions to enhance Openbravo ERP product to better suite the needs of different regions around the world.

This document describes the localization process for Openbravo ERP. It involves several collaboration tools and people and it's very important that you follow it carefully.

Basic localization process

  1. Check in the Current localization projects wiki page that there is no effort for your country or region. If there is an on-going effort, write the person listed as a contact and try to collaborate with her. If the person is not answering to your mails, send a message to the message thread for that effort explaining the situation and request to lead a new effort.
  2. If you are leading a new effort, you should follow these steps:
    1. Notify the localization coordinator at Openbravo of your effort sending an e-mail to Richard Morley <richard.morley AT openbravo.com>. Indicate also your schedule for your localization effort.
    2. A message thread for the localization effort should be created at the Localization forum.
    3. It is very important as a leader for an effort that you monitor the traffic for the message thread created for your effort. You can do so using the Monitor this forum option in the SourceForge forums. Note that the forums have been moved to Openbravo Forge.
    4. Send the details of your effort (indicating the address of the project forum to coordinate and your contact details) to Richard Morley <richard.morley AT openbravo.com>. He will register your effort in projects section of Current localization projects wiki page.
  3. The translations and chart of accounts are stored in the Openbravo Subversion Server. There is a page explaining how to use Subversion and you can also browse the translations and accounting directories. You should request an SVN account to Richard Morley <richard.morley AT openbravo.com> to be able to publish your work in our Subversion server. It is important to follow the repository structure in Subversion directories.
  4. Start the localization process.
    1. We request the localizers to upload their work to Subversion every two weeks in a pure open source approach, then people can follow your progress and give feedback to you.
    2. If you have any doubt or question, publish it in the forum created for your localization effort. Openbravo users and developers monitor that forum on a daily basis.
    3. If you think that your region has a functional or localization requirement that is not covered by Openbravo ERP, register it in our Localization Special Requirements page where we keep track of all of these.
  5. A translation is considered complete when all the user interface is translated. A chart of accounts should pass test1 and test2 to be published. We also strongly recommend to pass also test 3.
  6. Once your work is considered complete, a beta version can be published. Contact Richard Morley <richard.morley AT openbravo.com> to start this process. The process includes:
    1. Package the localization and make it available at Openbravo Forge where you can register a localization project.
    2. Prepare a note to announce it on the Openbravo Forge. See an example.
    3. Announce it in the localization forum.
  7. Keep the new versions of Openbravo up to date and repeat the process again.


Complete localization

  1. You should start by analyzing the most successful local solutions in your market. For example, for the US localization, a local solution such as Quickbook should be analyzed.
  2. Based on this analysis, you should define a list of localization gaps, which are features that need to be implemented in Openbravo in order to be competitive with that local solution. Please notice that you should focus on local capabilities only for this analysis and not on additional geography independent functionality; this is to a large degree a subjective assessment but it is important that your localization efforts do not get sidetracked by other potential functional gaps.
  3. Contact Openbravo localization team: collaborate AT openbravo.com
  4. Collaborate: join efforts from country community members.
    1. A message thread for the localization effort should be created at the Localization forum.
    2. It is very important as a leader for an effort that your monitor the traffic for the message thread created for your effort. You can do so using the Monitor this forum option in the SourceForge forums.
  5. Openbravo team will create a branch in our subversion repository for the project following the naming conventions and will give you the rights to develop there.
  6. Get a developer ID. Note: this is not needed starting with r2.50.
  7. Get rights to access the new branch (user and password)
  8. Write a functional and technical documentation for the project.
  9. Do continuous merges from trunk to your branch to keep updated and avoid future problems.
  10. Packaging:
    1. OB 2.40: Country OB version can be created from the branch.
    2. OB 2.50: A module for the specific country can be created from the branch.

Any particular development that makes sense to be included as part of the product core can be developed separately and contributed to the core. This means not taking care of that code any more. Openbravo team will help you doing the functional and technical specification but also will take care of that piece of code for future versions compatibility. See contributor guide.

Localization modules

The modularity features of Openbravo ERP 2.50 onwards enable localizers to create a discrete extension module which can be easily developed and shared with other users via the Openbravo central repository. It is strongly recommended that you use a module for any localization effort.

There are many different types of localization module. This document particularly explains how to create translations, charts of accounts and standard reference data modules, since these modules have a specific registration process.

You can also combine modules to create a localization pack.

In general, there are three stages to creating a module:

To learn how to work with modules, consult the video tutorials and the modularity developer's guide. Once you are confident with the concepts and techniques, use the guidelines that follow to specifically create localization modules.

Naming guidelines

For guidelines on naming modules please follow this link.

Java package naming conventions

Openbravo follows a Java package naming convention of: domain.contributor.module_name

Openbravo reserves the right to use org.openbravo as the domain and contributor designation, for example org.openbravo.initial_data_load.

Other organizations creating modules should use their own own organization name as the contributor designation when naming Java packages (unless there is a specific code contribution agreement in place that requires otherwise).


Examples of Java package names

The following table contains a description of recommended practices when naming Java packages:

Note:

langcode = ISO 639-1 language code

CTRYCODE = ISO 3166-1-alpha-2 country code


Module type Explanation Java Package Name Format Java Package Name Example
Chart of Accounts where there is a standard chart for a country Hungary has a standard chart of accounts. domain.contributor.accounts(CTRYCODE) com.mycompany.accounts(HU)
Chart of Accounts where there is more than one chart per country In Spain small companies use a chart of accounts called PGC 2007 PYMEs, while larger companies use a different chart. domain.contributor.accounts.accounts_name(CTRYCODE) com.mycompany.accounts.pgc_2007_pyme(ES)
Translation of Core The translation of core Openbravo into Arabic for Saudi Arabia domain.contributor.translation(langcode_CTRYCODE) com.mycompany.translation(ar_SA)
Translation of Module The translation of the Tax Report Launcher module into Spanish. domain.contributor.translation.module_name(langcode_CTRYCODE) com.mycompany.translation.tax_report_launcher(es_ES)
Tax configuration module Configuration of taxes for a particular country domain.contributor.tax_configuration(CTRYCODE) com.mycompany.tax_configuration(FR)
Tax report module A tax report for a particular country, e.g., Spain has a tax report called Modelo 347 which is delivered as a module domain.contributor.tax_report.report_name(CTRYCODE) com.mycompany.tax_report.modelo_347(ES)
Region modules A module that delivers names of regions (counties, states, regions) within a country, for example the regions of Brazil. domain.contributor.regions(CTRYCODE) com.mycompany.regions(BR)
Report modules (other than tax reports) A generic report in a particular language that can be used everywhere, for example a “Shipments Awaiting Invoice” report in English. domain.contributor.report.report_name(langcode) com.mycompany.report.shipments_awaiting_invoice(en)
Skin You like blue.... domain.contributor.skin.skin_name com.mycompany.skin.blue_sea
Tutorial Modules developed purely as examples to illustrate how to develop modules domain.contributor.tutorial.tutorial_name com.mycompany.tutorial.solitaire

Creating a translation module

For detailed guidance on translating Openbravo ERP please visit the Translating Openbravo page.

Important The section that follows is the recommended way to install a translation for Openbravo ERP 2.50 onwards. The previous methodology as described in these instructions is still available as an option.

To create a translation module follow the guidelines in the developer's guide and tutorials, but using the specific configuration described in this document. The process for creating a translation module is as follows:

  1. Register the translation module with the central repository.
  2. Export the database
  3. Obtain the xml files
  4. Translate the xml files
  5. Package the module
  6. Upload the module to the Openbravo Forge

Registering the translation module

When you register the module, fill in the fields as follows:

When you click Register Module you will be asked to supply your username and password for the Openbravo Forge. In the Forge, a module must be associated to a project.

Exporting the database

When you have registered the module, the next stage is to export the database to create the necessary module folders.

  1. Execute the command: 
    ant export.database
    Exporting the database creates a new subfolder within the Modules folder. The new folder has the same name as the java package of the translation module, for example modules/org.openbravo.mymodule.es_ES.
  2. Within the modules/org.openbravo.mymodule.xx_YY folder, manually create a subfolder called referencedata. You must use this exact name, note that it is all lower case and has no spaces.
  3. Within the referencedata folder, create another subfolder called translation.
  4. Within the 'translation folder create another folder for the translation, using the xx_YY language / country code naming convention. For example en_US for US English. 
    modules/org.openbravo.mymodule.xx_YY/referencedata/translation/xx_YY/
  5. Place the translated .xml files within the folder for its respective language.

Obtaining the .xml files

  1. Enter the ERP application as a System Administrator and go to General Setup > Application > Language menu option.
  2. Search for the language that you want to translate.
  3. Mark the System Language check box and Save the record (it has a disk as an image). Do not check the Base Language check box
  4. Press the Verify Languages button to create the records for the language. (if you already performed this action, result of the process should be 0, otherwise, the amount of new records created will be shown). An easy way to confirm that the process run correctly, is to check that new lines have been created in the translation tab of the windows. For example:
    • Go to Application Dictionary > Setup > Element.
    • Go to Translation tab.
    • Verify that a new line has been created for the language chosen. The contents of the tab should be in English. The real translation will take place in the following steps. If there is no new line, make sure you have saved the record after checking System language check box, and press Verify language again.
  5. Go to General Setup > Application > Import/Export Translations. Select the language and press Export.
    This step will create a folder hierarchy in the attachment folder you have defined (attach.path property) in your Openbravo.properties file. That folder hierarchy will be placed in a folder named lang. In that folder there will be at least two folders. One will be en_US (the default language Openbravo ERP comes with). And the second one will be the one you have exported (e.g. de_DE for German or es_ES for Spanish, see the previous table).
  6. Enter the folder of the language you have exported. You will be able to see an amount of .xml files and an amount of subfolders. The .xml files are the ones belonging to core. The subfolders you can see are the ones that contain the .xml files that belong to each module you have installed.
  7. Open the .xml files of the module you want to translate (not the files of the translation module).
    Note that there are many .xml files. The different objects to be translated are ordered in these files with a criteria. For further information follow the link at the beginning of the Creating a translation module section.

Translating the .xml files

You can now translate the .xml files using your preferred editor. Translate the text and change isTrl to Y in the ones you have translated. When you have finished translating, copy all the .xml files you have already translated from 

attach.path/lang/xx_YY/org.openbravo.mymodule/*.xml

to the recently created module folder hierarchy 

modules/org.openbravo.mymodule.xx_YY/referencedata/translation/xx_YY/

Packaging the module as an .obx file

To package the module, execute the command ant package.module -Dmodule=modulename, where modulename is the Java package name of the module.

Publishing the module to the Openbravo Forge

You are now ready to publish the module to the Openbravo forge

Translating core 3.0 version. Creating a translation pack

3.0 version of Openbravo

Since 3.0 version of Openbravo, the ERP is not just the core module, but a set of some other modules more. Because of that, in order to translate the ERP, it's necessary, not only to translate core module (as of now), but also to translate all the set of modules that makes the 3.0 version. So, the translation of 3.0 is not a translation module, but a set of translation modules. The best approach to manage this is to group all them together into one only pack.

Creating a Translation Pack

If a set of translation modules needs to be released as one only module (to avoid user having to install a lot of different modules), a pack can be created. If this pack includes all the set of translation modules that developer wants to install, when user installs the pack, all those modules will be installed.
Having into account the way dependencies are managed, there are some topics that developer must take into account when building a translation pack. Let's take, as an example, 3.0 RC3 version of ERP. This version is composed of the following modules and versions:

From these set of modules, only these ones do need to be translated:

In a fresh clean instance of 3.0 RC3, the translation modules are installed, or created. The process of creating or updating the xml translation files is run. Once all the files are up to date, then a new package is created. This package will include all the translation modules. Then, the package is created through two easy ant tasks: 

ant export.database
ant package.module -Dmodule=java.package.name.of.the.pack

Important things to take into account

All the translation modules must be created in a exactly identical environment: same core version, and same translated modules versions. Otherwise, the pack may not install correctly. If all the translation process and packaging is executed in the same environment, all these problems will be avoided.
It's important, before exporting the database, to update the version of the module that is translated, in the dependencies tab. So, before exporting the database, go to the Module window, and for the record that corresponds to the translation pack, go to the Includes sub-tab. There, update the version of the included modules to the one actually installed in the system. 

Tip: A fast way to do this is to go through all the entries in the Includes sub-tab,
change the selected module in the combo to whatever other one, and choose again the original one.
The call-out will fill-in the version field with the installed one.

Creating a chart of accounts module

The chart of accounts describes the accounting structure that Openbravo ERP uses. You can create a chart of accounts for a specific locale, for example to accomodate local accountancy practice or regulation. The chart of accounts consists of a .csv file that can be applied to a Client during the initial client setup process.

Before version 2.50, charts of accounts were downloaded from sourceforge and you can still use the Openbravo forge to upload and download charts of accounts. However, it is recommended that you create a module for charts of accounts and distribute it via the central repository because:

Creating a chart of accounts module comprises the following steps:

  1. Register the chart of accounts module with the central repository.
  2. Create the folder structure to hold the chart of accounts file.
  3. Create the chart of accounts file and save it in the folder structure.
  4. Package the chart of accounts module.
  5. Publish the module to the Openbravo forge.

Registering a chart of accounts module

When you register the module, fill in the fields as follows:

When you click Register Module you will be asked to supply your username and password for the Openbravo Forge.

Creating the chart of accounts file

Once you have registered the module, create the chart of accounts, using whichever package you prefer to create the .csv file.

Exporting the database

When you the chart of accounts file is ready, the next stage is to export the database to create the necessary module folders.

  1. Execute the command: 
    ant export.database
    Exporting the database creates a new subfolder within the Modules folder. The new folder has the same name as the java package of the translation module, for example modules/org.openbravo.referencedata.coa.ES_es.
  2. Within the Modules folder, manually create a subfolder called referencedata. You must use this exact name, note that it is all lower case and has no spaces.
  3. Within the referencedata folder, create another subfolder called accounts.
  4. Place the chart of accounts .csv file within the accounts folder.

Packaging the module as an .obx file

To package the module, execute the command ant package.module -Dmodule=modulename, where modulename is the Java package name of the module.

Publishing the module to the Openbravo Forge

You are now ready to publish the module to the Openbravo forge

Creating a standard reference data module

Standard reference data is data from Openbravo ERP's application tables, for example taxes and alerts. If you have set up Openbravo ERP in a particular way to meet local requirements, you can export this data and convert it to a module, so that you can share it with other users via the central repository.

The process for creating a standard reference data module is:

  1. Define and register the module in Openbravo ERP.
  2. Define and export the tables you require as a dataset.
  3. Package the module as an .obx file
  4. Create a project in the Openbravo Forge.
  5. Publish the module to the Openbravo Forge.

Registering a standard reference data module

Defining and exporting the dataset

  1. Log into Openbravo ERP
  2. From the Application menu, select Application Dictionary > Dataset
  3. Click New.
  4. From the Module list, select the module that will include the standard reference data.
  5. Specify a search key, name and description.
  6. From the Data Access Level list, select the Data access level from the following options:
    • System only
    • System/client
    • Client/organization
    • Organization
  7. Select the Export allowed option.
  8. Select the Table Tab
  9. From the Table list, select the table whose content you want to include in the module.
  10. In the SQL where clause field, specify the SQL "WHERE" statement that will identify the set of rows to be exported, in DAL notation. For example, client.id='1000001'
  11. To export all columns, select the Include All Columns option. To include only the columns you specify, select the Columns tab and create a new record for each column you want to export.
  12. To include the security audit columns (created, createdby, updated and updatedby) in the export, clear the Exclude Audit Info checkbox.
  13. Clear the Is Business Object option.
  14. Click Save
  15. Click the Export Reference Data button to export the reference data to an .xml file that you can include in the module.

Exporting the database

The next stage is to export the database to create the necessary module folders.

  1. Execute the command: 
    ant export.database
    Exporting the database creates a new subfolder within the Modules folder. The new folder has the same name as the java package of the translation module, for example modules/org.openbravo.referencedata.coa.ES_es.

Packaging the module as an .obx file

To package the module, execute the command ant package.module -Dmodule=modulename, where modulename is the Java package name of the module.

Publishing the module to the Openbravo Forge

You are now ready to publish the module to the Openbravo forge

Publishing the module to the Openbravo forge

Once you have created the .obx file, you can make it available to the community via the openbravo forge:

  1. In a web browser, navigate to the Openbravo forge
  2. In the Toolbox area, click Register Project.
  3. Complete the details of your module.
  4. Click Next.
  5. On the Services page, select the services you want to be avaiable for your project, for example a discussion forum.
  6. Click Finish.
  7. In the Toolbox area, select My Profile.
  8. In the My Modules area you will see that the module you registered in Openbravo ERP is listed. Click the module.
  9. To associate the module with the project you have created, select the project from the list. NOTE: Only projects without module associated will appear to be chosen
  10. Click Associate Project. The Publish Version page appears.
  11. Click Browse. Navigate to the location of your module's .obx file.
  12. Click Publish OBX File.

Special case: Initial Setup Reference Data

Starting from MP19 core provides a dataset with client/organization access level. It is available for applying to a new client or organization in the initial client/organization setup windows. The content of this dataset is, nowadays, the Standard Document Types to be created for the newly created client/organization, and all the collaterals needed for this, for example, sequences, jasper templates or g/l categories. Please notice that this dataset can be applied to clients, but also to organizations. Actually that is the best practice - have document types applied to the legal entities in the system. This way, if the company needs to create another legal entity that requires different configuration (document types, templates, etc), there will be no problem.

Any extension module can complement or extend Initial Setup Reference Data dataset. Let's evaluate it based on the example.

John is localizing Openbravo ERP for the region New Kingdom. New Kingdom authorities are very strict on the format and information provided in the invoices issued by every company in the region. Actually standard templates in the ERP for AP Invoice and AR Invoice documents are not valid, and as part of the localization new jasper templates have to be developed and released as an extension module.

John, then, performs an Initial Client Setup where the core dataset is NOT activated. The system will let him know that an important dataset has not been selected, therefore after the client is created, he will need to complete its configuration by either applying a datase to one of its organization or performing the configuration manually.

Then in the new client, performs a Initial Organization Setup, this time applying the core reference data module, as shown in the image:

LocalizationProcessInitialSetupReferenceData.png

(IMPORTANT: Being the first organization created in the system which applies the dataset, so first time the dataset is applied)

This will add:

  1. Document type named AP Invoice
  2. Template configuration for AP Invoice document type
  3. Document type named AR Invoice
  4. Template configuration for AR Invoice document type

Then John modifies the template for AP Invoice and AR Invoice documents mapping to the jasper report created by him to address New Kingdom authorities requirements. After that creates a module containing this jasper report, and with a dataset of data access level client/organization. This dataset is exported, and just the modified entries in c_poc_doctype_template table are included. This module is then packaged as Document type template for New Kingdom. As every other module, it will depend on a concrete version of core module.

Afterwards, this module is installed in a fresh instance. When accessing to initial organization setup window, both reference data sets are selected. System will, first, apply core module (according to set dependencies). Then will apply the module Document type template for New Kingdom, which dataset contains a row that will replace the one of the template for AP / AR Invoice documents.

Combining localization modules into packs

Creating localization packs offers a convenient way for users to implement localization modules. Packs are a particular type of module which consist of other modules, and creating a pack has a specific registration process. Once you have created the localization modules you require, follow these steps to combine them as a pack.

  1. Log into Openbravo with the system administrator role.
  2. From the Application menu, select Application Dictionary > Module.
  3. Click New. A new module record appears.
  4. In the Name field, give the package a name using the correct naming conventions.
  5. From the Module Type list, select Package.
  6. Complete the Description and Help fields using natural language and supplying as much information about the package as possible.
  7. Complete the rest of the module information as appropriate.
  8. Click Save
  9. Select the Include tab.
  10. Click New.
  11. From the Included module list, select the module you want to add to the pack.
  12. Click Save.
  13. Repeat steps 10-12 to include further modules in the pack.
  14. Package the module using following ant command: ant package.module -Dmodule. The parameter of the command is the java package name of the translation module. For example if the localization pack is called org.openbravo.package.czechlocalizationpack.CZ_cs,
    the full ant command would be: 
    ant package.module -Dmodule=org.openbravo.package.czechlocalizationpack.CZ_cs

Once you have created the pack, you can publish it to the Openbravo Forge in the normal way.

This category currently contains no pages or media.

Retrieved from "http://wiki.openbravo.com/wiki/Category:Localization_Process"

This page has been accessed 3,620 times. This page was last modified on 21 July 2011, at 17:08. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.