[tor-qa] Improving translation support (was pre-build announcement)

[Mike Perry]

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:
> 
> 1. 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 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, 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 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.
> 
> 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?


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-qa/attachments/20140315/638c1f12/attachment.sig>