anonym:
13/03/14 20:59, Mike Perry wrote:
anonym: In either case, we should only list locales supported in transifex though, it sounds like.
To avoid problem 3, yes.
An alternative approach to maintaining a static list of supported locales (which is error prone, see commit f9759b6 :)) would be to import and bundle/register all locales available in Transifex:
- In `import-translations.sh` we import all locales available in
Transifex into `chrome/locale`. 2. When packaging we register (in `chrome.manifest`) each locale (i.e. folder) present in `chrome/locale` that has all required translation files (i.e. the same files as the English locale). At the moment e.g. `ca_ES` and `ms` do not have all, so this check is necessary to not break those locales.
This would result in Tor Launcher bundling translations with lots of untranslated strings (possibly 100% untranslated in some) which I'm not sure how you feel about. OTOH, your current process doesn't guarantee anything about that even for the explicitly listed supported locales (except if you manually check). Still, one can easily make it so that only the locales specified by some env var are packaged, which seems to be what you want.
Yeah, bundling every locale by default increases the XPI size by almost 0.5MB, which means the compressed bundles get 0.5M bigger. However, the way you handled BUNDLE_LOCALES is quite elegant, and will result in xpis of minimal size in the existing TBB build process.
I am very interested in arriving at a solution that works for both of us out of the box, but I also want to maintain the ability to make it straightforward to verify that the list of locales in TBB, Torbutton, and Tor Launcher are the same. This is most easily done if we have a single line of locales in an env var.
Otherwise, your patch looks like a good direction to head in.
See the `locale_fix` branch on git://git.tails.boum.org/tor-launcher for an improvement using the "alternative approach" mentioned above.
In that branch, building a working package that includes all locales from Transifex' translations amounts to:
make import-translations git add src/chrome/locale git commit -m "Import translations." make packageNote 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, not that they have all required entities/strings. That would be a nice fail-safe against problem 1 but we'll have to find the appropriate tools first.
To only bundle selected locales, as you requested, 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 vi zh-CN" make packageUnlike 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.
Hopefully this suits your needs.
This is getting there. Functionally, it seems like exactly the right solution.
However, I noticed that the resulting XPI seems to have a chrome.manifest with multiple locale lines like: locale torlauncher chrome/locale//
This seems bad.
Can you file a ticket for this branch so we can track the whole translation importation improvement issue there?
We may want a couple more tweaks before merging this anyway. Also, can you squash down your branch to just a commit (or a commit per functional change) rather than preserving the history of the solution itself?