[tor-qa] Pre-build announcement for 3.6-beta-1

[anonym]

Mark Smith wrote:
> On 3/10/14, 1:35 PM, Lunar wrote:
>> The french build is broken. I have an error message “undefined
>> XML entity” on chrome://torlauncher/content/network-settings-wizard.xul
>> line 130, column 43 on &torSettings.bridgeHelp;
> 
> There are some new strings in Tor Launcher that need to be translated. 
> I don't know exactly what the interim process is since Mike has always 
> taken care of localization issues for us, but I think English strings 
> are usually pulled in for the untranslated entities.

As far as I can tell, DTD translation files are naively "applied" to the
XUL files, without falling back to English for missing entities. If an
entity is missing in the DTD, the resulting XUL keeps the entity name
as-is, producing invalid XUL like "<tag>&entity_name</tag>". This
explains the fatal error that lunar reported.

Problem 1: The above means that when a *new* string is introduced, all
existing translations are broken until they are re-imported via
`localization/import-translations.sh`, which depends on Transifex having
added the corresponding entity to all locales' DTD files. It looks like
the latter requires pushing the commits with the new string, and then
wait a bit. If that's correct, it makes this situation quite awkward for
anyone lacking push rights to your upstream repo, as they cannot package
a Tor Launcher with working non-English locales without manually
updating every single DTD file.

To make problem 1 less of a problem we could use a tool which can sync
all non-English DTD:s to the English one. It be invoked via something
like `make update-translations`, making it possible refresh the DTD
files so one can package a Tor Launcher that works for all locales
without having to involve Transifex (that can wait until right before
release time). I'm quite ignorant of XML/DTD stuff, but clearly
Transifex must make use of a tool like that. Any ideas about this?

Problem 2: Another issue is that `chrome.manifest` doesn't list English
as the first locale. If it did, English would be the fallback for
locales not listed in `chrome.manifest` (note that this would not solve
problem 1!). For the record, the current fallback is `af`, which doesn't
even have a directory in `chrome/locale`, so all unlisted locales are
broken.

Problem 3: However, `chrome.manifest` has a pretty exhaustive list of
locales, so the broken fallback isn't used in many cases. Unfortunately
most of them are pointing either to non-existing directories in
`chrome/locale` (fatal error similar to the one from problem 1), and to
existing directories which contain translations that are pretty much
guaranteed to be outdated (and hence probably hit by problem 1) because
they're not updated by `localization/import-translations.sh`. Hence all
these locales will experience similar errors to what lunar reported.

For problems 2 and 3 I think some `make` automation can improve the
situation quite a bit. See the attached patch for something like that.

I suppose you should see all this as an inspiration for a real fix, as
I'm not even sure how you want the translation process to work in the
end (perhaps you're fine with the current situation?). For the same
reason I've refrained from opening any bugs at this point.

For the record, the current plan for Tails 0.23 (due on 2014-03-19) is
to ship a Tor Launcher packaged with my patch applied, since the current
state of things breaks Tor Launcher in many locales we care about in Tails:

    https://labs.riseup.net/code/issues/6885

(Well, actually Tor Launcher is broken in *all* non-English in Tails due
to problem 1 alone, since I introduced a new string. However, your
commit a634ce6 fixed this, and my patch fixes the remaining issues, but
this still shows the severity of problem 1 for downstreams wishing to
package Tor Launcher with potential modifications, like Tails.)

Cheers!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fallback-to-English-for-unsupported-locales.patch
Type: text/x-patch
Size: 10538 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-qa/attachments/20140312/3ec177a7/attachment.bin>