#32636: Clean up locales shipped with Tor Launcher ---------------------------------------+----------------------- Reporter: gk | Owner: brade Type: task | Status: new Priority: Medium | Milestone: Component: Applications/Tor Launcher | Version: Severity: Normal | Resolution: Keywords: TorBrowserTeam201912 | Actual Points: Parent ID: | Points: 0.25 Reviewer: | Sponsor: ---------------------------------------+-----------------------
Comment (by gk): Replying to [comment:1 mcs]: > I am not sure what should be done for this ticket. The strategy for handling translations is different for Tor Launcher compared to Torbutton. That's true and is okay. What needs to get done is to adapt the locales to the code Mozilla is using as this got done server-side. E.g. we have now `sv-SE` we should use and not `sv` anymore. Otherwise the translations updating is not working anymore as expected. And while doing that there might be scripts we need to adapt. (You might easily see what we need to adapt by just fetching the latest translations) > For Torbutton, only locales listed in the `BUNDLE_LOCALES` variable within `import-translations.sh` are updated from Transifex, and we only ship some locales in Tor Browser (presumably, the set of locales listed in Torbutton's `jar.mn` file matches the set in `BUNDLE_LOCALES`). > > For Tor Launcher, the `localization/import_translations` script updates from Transifex and keeps the .dtd and .properties files for every locale that (1) includes all necessary files and (2) has any translated strings. Then a new `jar.mn` file is generated that includes all available locales, which causes us to we ship all of the locales in Tor Browser. The original reason for not excluding any locales was that that another application that uses Tor Launcher might use a locale that we do not use in Tor Browser, but I don't think any other application uses our jar.mn file. > > I have two questions for gk (or anyone): > 1. What do you mean by "removing the ones we don't support anymore?" Should we compare what is available in the translation.git repo with the locales that are in the Tor Launcher repo? Yes, and what Mozilla is actually providing. I suspect Tor Launcher is coming with more locales than the latter at least (`ru@petr1708` seriously? or `zh-CN.GB2312`) and it might make sense to reduce that so it matches better what Mozilla is providing as I think we won't be in a situation that Tor Launcher is shipped for a locale without a corresponding Mozilla one. > 2. Should we add a `BUNDLE_LOCALES` variable to Tor Launcher's `import_translations` script and use it to determine which locales are part of Tor Browser? I think reducing the locale-related lines that are added to the generated `jar.mn' file should be enough to reduce the set of locales that ship inside the browser. I don't see any harm in continuing to update Tor Launcher's locale files for locales that we don't ship, unless that creates too much pain when doing release work (updating translations). I don't have a strong opinion here. Whatever works for you works for me. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32636#comment:2> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs