[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #11483 [Tor Launcher]: Improve how Tor Launcher handles incomplete translation



#11483: Improve how Tor Launcher handles incomplete translation
--------------------------+-----------------------
 Reporter:  anonym        |          Owner:  brade
     Type:  enhancement   |         Status:  new
 Priority:  normal        |      Milestone:
Component:  Tor Launcher  |        Version:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
--------------------------+-----------------------
 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:

 {{{#!sh
 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:

 {{{#!sh
 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11483>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs