Created: 23/04/05 by RobertCollins
- Malone Bug:
This specification discusses the internationalization of Bazaar, its limitations and directions. Currently, bazaar uses gettext to translate the program input (with help from the community) from English to other languages.
However, perceived limitations in gettext prevented bazaar from implementing internationalization in certain circumstances, such as when program output is dependant upon the usage of variables.
Launchpad has an application called "Rosetta", which provides translation services for programs like Bazaar. This service has two, non-conflicting modes of operation: A developer can either download translations of a user uploaded version of the software or the most recent Ubuntu release of the software. This spec covers which approach to use. Under normal conditions, the most recent release of Bazaar is in Rosetta for translations. However, during freezes, the bazaar version is not updated in Rosetta for a period of three months.
Bazaar's internationalization has some limitations - options aren't internationalized, there are lots of similar but not identical strings. Without proper internationalization work, bazaar will not be useful for people who speak non-English languages. As such, internationalization for bazaar is a priority for the majority of the world.
The other half of the internationalization puzzle is to keep the translatable strings for bazaar as current as possible; strings that are not listed within Rosetta are not being translated. Thus, some sort of process needs to be defined that that ensures that untranslated strings are placed into Rosetta on a timely basis. Since automatic uploads from Rosetta are tied to the freeze state of Ubuntu, the current translation set needs to be uploaded manually on a weekly basis. Immediately after upload, the same developer should download the most recent translations and import them into Bazaar.
Scope and Use Cases
* Use Case 1 - A user, who has set his language to piglatin, runs baz getlay --elphay (baz get --help in piglatin) and sees the following:
usage: baz getlay --elphay [optionssay] evisionray [irday]
-h, --elplay Isplayday alay elphay essagemay andlay exitlay -H Isplayday alay erbosevay elphay essagemay andlay exitlay
Keeping close track of Rosetta is vital. As such, on a weekly basis, a Bazaar developer will download the most recent translations that have been completed and upload the new untranslated things. The process works thusly:
Once a week, download the previous translations (which will be superset of previous translations). Place these new translations in the bazaar po/ directory
Immediately after performing the previous step, run bazaar/po/etc/makepo.
- Tarball the bazaar working tree.
- Upload the previously created tarball to Rosetta.
On another subject, the current code currently does not print statically allocated strings. In those cases that bazaar defines the need to dynamically print something that is statically defined, one may perform a gettext request by passing the dynamic variable through gettext. As such, bazaar's opt.c (the function responsible for printing out bazaar help) will be modified to print out the help in the user's native language. For example:
occ_buf = occ_this = occ_next = str_save(0, opts[x].desc);
occ_buf = occ_this = occ_next = str_save(0, _(opts[x].desc);
Note: The string that is being translated must remain identical to the one that was statically defined.
Data Preservation and Migration
Existing data will be modified and updated as new translations are added via Rosetta. This addition is a natural, expected evolutionary step. As the data format does not change, no migration of old data needs to be performed. On a weekly basis, new translations from Rosetta need to be migrated into the development branch of bazaar.
User Interface Requirements
Code modification for the above listed information