Within the OpenERP source code, all translatable terms are written in international English (language code en_US). The Administrator of an OpenERP instance can install additional languages among the official translations. As a result the corresponding translations of all installed modules will be loaded in the database, and used to replace the default English terms in the application interface when a user changes her preferred language.
Regardless of what follows, if you are considering working on the OpenERP translations, please read the general Launchpad Translations Guidelines before writing your first translation, as it includes very important advice for new translators.
There are 2 ways for contributors to add or modify translations in their languages:
Work on Launchpad, OpenERP's community platform, using the dedicate Translation interface on Launchpad, formerly known as Rosetta. This guarantees to work on the latest translation, and is automatically synchronized with the .po files of the source code. See Translating with Launchpad for more details.
Work directly on the PO files, considering them as regular source code files, and thus sending a merge proposal of the .po patch to OpenERP, just like for a regular patch. This is explained in more details in Translating in the source code section.
The first solution is greatly recommended when you are working on official OpenERP translations, but sometimes the second solution is more efficient when you are translating new community modules. These two solutions also have different access rights requirements, as explained below.
Can I do batch translations locally and then upload the .po files in batch in Launchpad?
You can certainly translate locally, however Launchpad does not allow uploading back .po files directly, as you are normally supposed to work directly using their translation interface. You will need to work on translations using the alternative method, based on the .po files directly, as explained in Translating in the source code. We really recommand working with Launchpad instead, due to the numerous advantages, detailed in Translating with Launchpad.
Translating with Launchpad¶
Launchpad provides a web-based translation interface, which can be used to translate. Its main features are:
Being web-based, it is accessible everywhere for anyone and does not require any developer skill
It provides all the contextual information that a translator needs, and mentions the place where the term comes from inside the software, a critical information for proper translations.
Making use of the thousands of other open source project hosted on Launchpad, it is able to suggest similar translations from all other projects, speeding up the translator's work.
It provides reviewing features, and allows marking the terms that one thinks should be reviewed by other translators, easing collaboration further.
It comes with a specific access right system, and Launchpad Teams can be assigned to specific languages, making them responsible for the quality of the translations.
It is automatically synchronized with the source code files containing the translations, effectively replacing completely the need for manually updating them as explained in Translating in the source code.
After registering on Launchpad, you can access the translations for any OpenERP project by clicking on the Translations or Help Translate links on the homepage of the project. You may also find the list of all (official and community-driven) translatable OpenERP-related Launchpad projects: https://translations.launchpad.net/openobject.
Some quick links to the main OpenERP projects' translations:
Permissions for Translations on Launchpad¶
OpenERP uses structured permissions for the Launchpad translations, which means three things:
Anyone is always free to suggest translations for OpenERP modules, clients and server.
If no translation team is assigned to a language, anyone can review or even accept a given translation.
If a translation team is assigned to a language, only members of that team are allowed to review and accept the translations in this language, but anyone can still suggest translations.
See also Launchpad's Translations documentation for more details:
Requesting the creation of assignation of a translation team¶
If your language does not yet have an assigned translation you are free to create one yourself, and request its assignation to that language. If the team already exists, please contact its members to join their effort.
If you decide to create a new team (anyone can do that), please name it openerp-i18n-XXX where XXX is your language, for example openerp-i18n-dutch. Please be sure to put a complete description for the team, explaining its purpose, how to join (if you want to make it moderated or restricted, etc.) The description can be in your language, and you could look at the description of existing translation teams if you need examples. Please also have a look at the Launchpad recommendations for running a Localization team.
When this is done, send a message through Launchpad to https://launchpad.net/~odo, requesting the assignation of your new team.
After this point, anyone will still be free to propose and view translations for your language, but one will need to be a member of your new team to be able to validate/accept them.
Reviewing translations on Launchpad¶
When a translation team is assigned, it is in charge of reviewing every translation made by the contributors before they can be used in the official packages and branches.
If you are a member of a translation team, please make sure that new suggestions are reviewed as soon as possible. There are few things more disappointing than contributing and having your work ignored! Fortunately Launchpad makes it pretty easy for you to keep up.
You can see how many strings need review on the project's translation page for your language. Just click on the number in the column "Need review" will directly open a page with all the contributions waiting to be reviewed:
One of the neat features of Launchpad is that it can keep several suggestions for translating the same string. Launchpad will also suggest translations made in completely different projects if it can. As a reviewer, you are free to either choose the translation you find best, or to make a new translation yourself.
When none of the suggestions are good enough, you can also discard them by checking "Dismiss all suggestions above.". They will be removed from the review process and fall into oblivion - use wisely.
Requesting review for your own translations
While you are in charge of reviewing other's translation, you may also wish to new translations of your own, and have others review them. To this end, launchpad will present you with an additional checkbox labeled "Someone should review this translation". If you check this box, your contribution will be considered as a suggestion rather than a reviewed translation.
If you are making lots of translations that to want others to review, just leave the "Reviewer mode" to enter the "Translator mode". Launchpad will then check the box automatically for you.
Why am I credited for translations when I only reviewed someone else's contribution?
When reviewing translations, you must be careful to select the suggestion and not copy/paste it into the "New translation" box, otherwise Launchpad may consider the contribution is yours.
Also, if you change even a tiny bit from the translation (like correcting a small type), it will be considered a new suggestion and credited to you.
Translating in the source code¶
As an alternative to Launchpad, translations may also be done in directly in the source code, considering the translation files as regular source code files. The result of a translator's work is essentially a regular patch, which may only be published according to the specific permissions allowed on each project code. To the contrary, when using Launchpad any validated translation is directly committed by Launchpad in the official branches, without any further delay.
As no-one outside of OpenERP's Quality Team is allowed to directly commit patches on the official branches, this means that a translation patch for the official OpenERP project would need to be submitted using a regular merge proposal, as described in Merge Proposals & Patches.
If you still want to use this technique, perhaps because you want to update all your translations in one batch (which is not possible with Launchpad yet), you will first need to understand the Translation files structure.
The you can start editing the .po files directly using a PO editor such as POEdit, or instead update the translations directly within OpenERP, and replace the existing .po by exporting updated ones using OpenERP's translation export wizard.
We recommend you follow these steps to ensure the best result with this technique:
read everything about the Translation files structure
grab the latest source code and create a new OpenERP database to start with, to make sure you have all the latest translation terms
translate locally using OpenERP's interface or any other way you like
if translating in OpenERP, re-export all .po files of your language for all modules over the current ones in the source using OpenERP's export wizard
at that point you basically have a version of the code where your languages's .po files are patched. You then need to commit and push these changes into a public branch on LP and make a merge proposal so OpenERP's quality team can merge the updated .po files into the official branches. Follow the regular procedure as explained in Merge Proposals & Patches.
Translation files structure¶
Promijenjeno u verziji 5.0: and 6.0
As of version 5.0, OpenERP uses exclusively the GetText Portable Object (a.k.a. *.po ) standard format for storing translations. Numerous tools and libraries are available on most platforms and programming languages to deal with this widespread format.
The translations are organized in several translations domains, where each domain is a topic-specific area of OpenERP. Each domain has a separate list of translatable terms, described in what is called a PO Template file, usually called domain.pot and found in a i18n  subdirectory specific to that domain. Each OpenERP client (GTK/Native and Web) represent a separate domain, and each OpenERP module is also a separate domain.
A domain template file does not contain any translation, but only lists the available terms to be translated. Translations are regular .po files that should be located in the same subdirectory as their domain template, and respect the following naming convention.
Domain templates files must be named domain.pot and located in a po or i18n subdirectory.
For OpenERP 5.0, translation files must be named lc_CC.po after the corresponding country and language code from ISO 3166  and ISO 639-1 . For example a translation in French from France would be fr_FR.po while one for Brazilian Portuguese would be pt_BR.po.
For OpenERP 6.0, translation files must be named lc_CC.po after the corresponding country and language code from ISO 3166  and ISO 639-1 , except for the canonical combinations, such as French from France or Portuguese from Portugal, which must only have the language code. For example a translation in French from France would be fr.po and one for regular Portuguese would be pt.po, but one for Brazilian Portuguese would be pt_BR.po.
If you were looking for the domain template and Belgian Dutch translation of the account module, you would look for the following files in the addons project:
account i18n account.pot nl_BE.po
i18n is a common shortcut for Internationalization, as there are 18 letters between the first i and last n in this word.