Posts Tagged ‘rosetta’

There’s been quite a few changes recently regarding the translation process of OpenERP, and this may be confusing for the community, as discussed recently on the community mailing-list. So here is an attempt at clarifying the translation process(es).

Translations are currently managed a bit differently in the stable and trunk series, for technical reasons. This will be unified as soon as the next major version is released, in a few months. We will also update the documentation (developer book) to reflect this. Until then, we must live with a different system in the stable version. Here’s the situation:

Trunk / Development version / 5.2

  • In trunk, all translations are automatically synchronized between LaunchPad’s translation system (Rosetta) and the various *.po files that are located in the source code.
  • Whenever someone commits a change to a .po file, LP detects it and displays it in the interface. Conversely, whenever someone changes a translation via LP, it is automagically commited in bazaar by LP after a while.
  • Translators can work term by term via LP, or download/upload multiple terms at once in a .po format via LP too. The translation interface is easy to locate, e.g https://translations.launchpad.net/openobject-addons
  • Access rights on translations updates and reviews via LP are given to the various translation teams setup in LP.
  • LP requires PO files to be named with the language code by default, so all PO files were renamed accordingly (e.g. from nl_NL.po to nl.po), so that LP’s commits go into the right files.
  • When loading the translation for a language, OpenERP trunk will try to find a country-specific PO first (e.g. nl_NL.po) then fallback to the default language one (e.g. nl.po) if there is none.
    Update: after confirmation, here is the exact behavior: OpenERP will look for the default language file if the language and country code are identical (e.g. if user has nl_NL, it will load nl.po), and only look for a country-specific PO if the country and language code are different (e.g. nl_BE). It will then fallback to the default language PO if no country-specific PO is found.
    This is compatible with LP’s strategy and also allows per-country specific translations.
  • LP expects to find the POT (PO template containing all translatable terms) file as the only file with a .pot extension in the same directory as the various *.po files that contain the corresponding translations.

Stable version / 5.0.x

  • In stable, there is no automatic synchronisation of LP’s translations with the *.po files, because it requires some core changes (partially outlined above for trunk).
  • Even without automatic sync, translations can still be done in LP’s translation interface, however the URL to access it is less obvious: you will find links to other series’ translations via the trunk translation pages.
    e.g: https://translations.launchpad.net/openobject-addons/5.0/+translations for standard addons
  • During the few months remaining for 5.0, the synchronization is thus done manually by the Release Manager at Tiny. Before releasing a new stable release, the Release Manager must import all LP translations and commit them in the stable branches. Fortunately this manual process will not be needed as of 5.2.
  • Translators can work in the same fashion as for trunk, term by term or by .po files, and access rights on translations are managed in the same way.
  • OpenERP 5.0.x requires PO files to be named using the full language_country code (e.g. nl_NL.po), with no fallback mechanism, so the Release Manager and other contributors directly touching PO files need to do so in the correct files.

As a final note, there is no automatic process to merge translations between stable and trunk in LP, so it must be done manually during the periodic merges that are performed from stable into trunk.

See also the FAQ for LP’s Rosetta system, if you are interested in translations.

Hopefully this clarifies things a little bit…


Read Full Post »