Goals

Primary:

• Enable translation of the hildon binary packages Mobile uses into arbitrary languages.

Secondary:

• Automate the process as much as possible

The Problems

The Domain Problem

Many/most gettext binary packages use a gettext "domain" of the same name. For example, the drivel binary package uses the gettext domain "drivel". (Operationally, the result is that drivel looks in the current locale's messages directory for a binary translation file named "drivel.mo" to lookup translated strings.)

Hildon binary packages we use don't generally have gettext domains of the same name. Some hildon binary packages use multiple different domains. For example, hildon-desktop binary package uses the following domains, among others: maemo-af-desktop, hildon-fm. Multiple packages use common domains.

Therefore, it necessary to derive a list of domains used by applicable hildon binary packages. For every locale, these domain files must exist and must contain the appropriate translations.

The Mapping Problem

Binary domain files cannot be read, therefore we need the source versions of the domain translation files.

With hildon, source translation files (called "templates") are generally not produced by the source packages that produce the binary packages that use them.

Therefore, the source packages that produce the required templates must be identified.

The Non-English-Strings Problem

Gettext translation depends on the convention that the template file contains the strings that are to be translated. However, in hildon they do not. Instead they contain logical codes that are mapped (using unavailable documents) to their intended meaning. Presumably, translators consult these unavailable files to produce actual translations that correlate the logical strings ("msgids") to the translated strings ("msgstr"s)

Therefore, it is necessary to derive the intended meaning of every string that needs to be translated.

The Translation Method Problem

Launchpad displays the the raw strings from the template to the translator for translation. Since with hildon, these strings are not meaningful, Launchpad cannot currently be used to translate hildon.

Whether to translate manually or to use Launchpad, in the short term and in the longer term, is an open question.

The Solutions

The Domain Solution

• I made a list of binary packages I believe to be hildon from a nightly build manifest.
• I found the source packages for each as follows in a maemo trunk svn co tree:
  • First, find control files and grep the "Package: (package)" to discover the directory that contains the source package that generates the binary package.
  • Then grep the debian control file in the source packages directory for the source package name, as follows.

user@system:~/src/maemohildon/trunk$ find . -name "control" | xargs grep -r "Package: gtk2-engines-sapwood" 
./sapwood/debian/control:Package: gtk2-engines-sapwood
./sapwood/debian/control:Package: gtk2-engines-sapwood-dbg
user@system:~/src/maemohildon/trunk$ find ./sapwood -name "control" | xargs grep -r "Source: sapwood" 
Source: sapwood

• Here are the results:

• I wrote a python tool getdomains.tar that, given a list of source packages, apt-get source <pkg> downloads them, or optionally uses present source packages (for example those manually downloaded form the maemo svn repo), and generates a report of domains called by source in each package, both the default domain set for the package, and specifically named domains used in various dgettext calls (dgettext, dngettext, dcngettext). The report is not absolute, since such variables are set in various ways, and some further analysis of the results is needed, however it provides a known list domains used and a list of possible domains that need further evaluation.

Using this approach, I have generated a list of required domains for what I think to be the current the set of binary hildon packages.

The Non-English-Strings Solution

• It turns out that Maemo's SVN hildon source tree (https://stage.maemo.org/svn/maemo/projects/haf/trunk/) contains source packages for most (or all, to be confirmed) of the domains. For example, there's one named maemo-af-desktop-l10n that has the maemo-af-desktop domain source files, and there's one named hildon-fm-l10n that contains the hildon-fm domain sources files.

• Each such package contains a template and a translation for the English/Great Britain locale.
• The English translation file contains the information required to correlate the logical code in the template (what is used in code) to its intended meaning. This is because the logical string (the "msgstr") is already translated (the "msgid"), thus we can see what the logical string means.

The Translation Solutions

• Having obtained the required English translation files for all required domains, we could copy the English translation for every required locale and manually translate them, using the English translation as the basis as described above.
• Or, we could process the English translation files into valid template files (by switching the English translation with the logical string), upload them to Launchpad as normal template files, translate them, reprocess them (switching the English back to the logical string), before converting them to required binary domain files

Note that these source domain files may contain much data that is not relevant to Mobile since we do not use the same set of packages as maemo. Depending on the cost of translation and the size of the effort, it may be worthwhile to evaluate means of translating only required strings. This could theoretically be done by processing source files to determine the list of strings used in packages and then translating only those.

Preliminary Results

Using this methodology, I found:

• The following domains are
• Called by the indicated Hildon source packages
• And they correspond to source template files in the indicated maemo svn trunk source projects:

Thus, we can use these source template files in combination with the English translations also found there to accomplish the bulk of Hildon translation, whether manually or via Launchpad.

The following domains are called, but I can't yet find the corresponding source templates, and further analysis is required, as to whether we really need them, and etc.:

• osso-applet-tasknavigator
• ke-recv
• osso_help

The following source packages do not appear to have internationalized strings: sapwood, libosso, libhildonmime, hildon-thumbnail

Open Questions

• Given the current Hardy cycle, if we manually translated Hildon, could we still get the results into language packs for buiding images and downloading languages at run time?
• Given the current Hardy cycle, can we still use launchpad to translate hildon at all?

Adding Strings to Hildon

It may prove necessary to add strings to hildon that are exposed in the UI and require translation. But, we may not want to add these to hildon domain source packages/template files due to time and other constraints.

Therefore, we should consider using our own, possibly temporary, domain, perhaps ubuntumobilehildon. This would require specifying the domain in code when using the string, maintaining the template file, and managing the translation and etc.