Localization/Workflow
Jump to navigation
Jump to search
Overview
The current localization workflow mainly deals with translation of the software user interface (for example, the UI of an activity like Browse, or the Sugar Control Panel). We are working on getting content (wiki, website, educational material) integrated into our workflow - please see the Challenges section below.
Goals (current)
The goals of localization are
- To ensure that software in the shipped laptops supports at least, the primary language spoken in the deployment region. This means ensuring
- Script support (eg: For a deployment in Ethiopia, you need to make sure that the Amharic script can be rendered in the user interface, and activities such as write support them)
- Reasonable level of user interface translation (at least greater than 80% of sugar and the core activities translated)
- To ensure that other regional conventions aspects (keyboard layouts, date/time formats) are also supported as much as possible by the laptops
The workflow
At the translator's side
- A mirror (clone) of the relevant git repositories (from dev.laptop.org) exists on the crank.laptop.org filesystem.
- Strings from the software are extracted by an utility called intltool and collated into a POT (Portable Object Template) file.
- A cron job on periodically runs intltool to ensure that the extracted strings are up to date
- Copies of the POT file exist for each language being translated into. The copies of the POT file are called PO (Portable Object) files.
- The PO files are merged with the POT file to avoid "stale" translations on a weekly basis
- A web based software called Pootle accesses the PO files and presents them in a simplified manner to the translators
- Translators log in via Pootle, and translate the strings into their own language
- Translators also have the option of offline translation (ie, they can download a PO file, translate it, and then re-upload it back again)
- An administrator (a translator with extra privileges in Pootle) can commit a translated PO file (using the web based interface) - which triggers a "git push" of the translated PO file into the dev.laptop.org Git repository
At the developer's side
- Before making a package release, developers pull the latest translations from the dev.laptop.org Git repository into their personal repositories.
- The build system (both autotools based as well as bundlebuilder based) converts the PO files into MO (Machine Object) files
- The MO files are loaded at runtime (based on the value of the LANGUAGE or LC_ALL or LC_MESSAGES or LANG environment variable) and the translated strings are extracted out of the files and shown to the user via the UI.