This document describes the best practices and polices to apply in Openbravo Forge to develop and organize a localization project.
Many countries and regions have similar requirements, like sharing the same language or functional requirement. To be able to reuse localization components, we provide the following types of projects to enable functionality delivery:
- Module: provides an atomic functionality. Examples of modules are chart of accounts, translations, banking interfaces, etc.
- Pack: group all the modules necessary to enable Openbravo ERP for a country or region. For example, the Spain Localization Pack that contains a full localization package for Spain.
We recommend that:
- Each country or region should create one and only one pack that contains all the relevant modules. A pack should be created for consistency sake even if it contains only one module.
- Each country or region could create zero or more modules (zero if it only reuses modules and does not create any geography specific modules)
When registering your localization pack project for your region, we recommend to enable the following services in Openbravo Forge:
- Module: to publish the pack in the central repository
- Forums: to discuss localization issues for the region that the pack targets
For localization packs, we suggest to discard the usage of the rest of the services that the Forge provides.
Additionally, we recommend:
- Since a pack groups modules, they should not contain code, and as result, they should not require a source control system.
- We recommend to report issues, using the bug tracking system, to each particular module instead of reporting to a pack.
- We only recommend to publish files in the download area during the development cycle, you post your obx file in progress in the download area for early adopters to download and evaluate. We do not recommend to publish the files in the download service once they
are released since you can already download files published in the central repository.
- When registering the project, assign it to the Openbravo ERP -> Localization Packs category.
When registering your localization modules, we recommend to enable the following services:
- Module: to publish the module in the central repository
- Code: to develop the code of the module and be able to work in a collaborative manner with other developers
- Bug Tracking: to allow users to report issues or functionality enhancements
- Wiki:to publish documentation for the project and to coordinate work
For localization modules, we suggest to discard the usage of the rest of the services that the Forge provides.
Additionally, we recommend:
- We only recommend to publish files in the download area during the development cycle, you post your obx file in progress in the download area for early adopters to download and evaluate. We do not recommend to publish the files in the download service once they are released since you can already download files published in the central repository.
- When registering the project, assign it to the Openbravo ERP -> Localization Modules category.
For naming localization projects we recommend the format Name of the country + Description, except for language modules that we recommend Language name + for + country.
For example, for Spain we use the following names:
- Spain Localization Pack. Contains all the modules necessary to apply the localization for Spain.
The following table contains a description of the best practices when naming packages.
|Contributor type||Domain||Contributor||Contribution type||Content||Locale||Example|
|The creator of the content|| Top level domain of the creator, for
example: com, org or edu
|Creator’s name|| Select from: module, accounts,
| Description of the content. If the
contribution is a translation then identify the language using ISO639_1
| ISO 3166 country code of the locale
for which the contribution is intended
|3rd party contributor||com||mycompany||accounts||small_company||MX||com.mycompany.accounts.small_company.MX|
|3rd party contributing under a specific code contribution agreement||org||openbravo||translation||es||ES||org.openbravo.translation.es_ES|
* Please notice that, if your module is going to implement some Java classes, then no capital letters should appear in the package name. For example, org.openbravo.module.taxes.es will work, but org.openbravo.module.taxes.ES may give some problems, because do not fit Java naming conventions.
- Localization process. Recommendations on how to structure packs and develop modules.
- Openbravo ERP localization forum for discussing and getting help on Openbravo ERP related localization issues.