Now that legacy/trac#29941 (moved) is basically fixed on the server-side we are getting all the new goodness with the next translations fetch. We should clean-up the locales we ship while doing so (removing the ones we don't support anymore etc.). Additionally, we should adapt all the scripts around translation update imports if that's needed. And, after checking everything is still working we need to backport the changes to a stable branch (as the locale updates that landed in 9.5a3 will ride the train).
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
I am not sure what should be done for this ticket. The strategy for handling translations is different for Tor Launcher compared to Torbutton.
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):
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?
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 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):
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.
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.
Unfortunately, the patch is somewhat large due to all of the locale updates (including removal of a bunch of old locales). The good news is that after this is merged we will ship a lot fewer locales within the Tor Launcher part of Tor Browser.
Trac: Keywords: TorBrowserTeam201912 deleted, TorBrowserTeam201912R added Actualpoints: N/Ato 0.4 Status: new to needs_review
Unfortunately, the patch is somewhat large due to all of the locale updates (including removal of a bunch of old locales). The good news is that after this is merged we will ship a lot fewer locales within the Tor Launcher part of Tor Browser.
We can probably make our lives slightly easier by injecting the list of locales into the script via an environment variable. tor-browser-build should be able to set that for us. in the script, if that environment variable is not set then it can use a default value, like the current one.