GitLab

There are a number of issues when incomplete translations are present in Tor Launcher, as described in more detail in this thread: https://lists.torproject.org/pipermail/tor-qa/2014-March/000355.html

In short, while DTD translations can do the job, they're error prone and pretty much broken by design since there's no per-string fallback. Instead, if a single string is undefined in a DTD translation, this will cause a fatal XUL error.

Tor Launcher does not register the "en-US" locale (instead it registers "en"), which is the fallback for unregistered locales, so the fallback simply becomes the first registered locale, which happens to be "af", which is incomplete (=> XUL errors). Furthermore, Tor Launcher has a pretty much exhaustive list of locales it does register, most incomplete (=> XUL errors).

Improvements, not complete fixes, for all this can be found in the locale_fix branch on git://git.tails.boum.org/tor-launcher. The commit messages should be pretty clear on how exactly.

In that branch, building a package that includes all current translations from Transifex' translations amounts to:

make import-translations
git add src/chrome/locale
git commit -m "Import translations."
make package

Note that we have to assume that Transifex' translation repos are up-to-date; we only ensure that each bundled locale has the necessary .dtd and .properties files (otherwise they are skipped), not that they have all required entities/strings. That would be a nice fail-safe against those fatal XUL errors but we'll have to find the appropriate tools first.

To only bundle selected locales one exports BUNDLE_LOCALES appropriately, e.g. with your old list:

export BUNDLE_LOCALES="ar de es fa fr it ko nl pl pt ru tr vi zh-CN"
make package

Unlike the rather optimistic "bundle everything" case, this will throw an error if any of them couldn't be bundled for whatever reason, as a fail-safe. Also note that the "en-US" locale is always automatically included since it's the fallback.