Opened 8 months ago

Closed 7 months ago

#32636 closed task (fixed)

Clean up locales shipped with Tor Launcher

Reported by: gk Owned by: brade
Priority: Medium Milestone:
Component: Applications/Tor Launcher Version:
Severity: Normal Keywords: TorBrowserTeam201912R, tbb-backported
Cc: mcs, sysrqb, tbb-team Actual Points: 0.4
Parent ID: Points: 0.25
Reviewer: Sponsor:

Description

Now that #29941 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).

Child Tickets

Change History (6)

comment:1 Changed 8 months ago by mcs

Cc: tbb-team added

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):

  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?
  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).

comment:2 in reply to:  1 Changed 8 months ago by gk

Replying to 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.

  1. 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.

comment:3 Changed 8 months ago by mcs

Actual Points: 0.4
Keywords: TorBrowserTeam201912R added; TorBrowserTeam201912 removed
Status: newneeds_review

Here is a patch for review:
https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug32636-01&id=d95b8fa0448623bdd47b32b8b3ce60274bc3c540

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.

comment:4 in reply to:  3 Changed 7 months ago by sysrqb

Replying to mcs:

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.

comment:5 in reply to:  3 Changed 7 months ago by sysrqb

Replying to mcs:

Here is a patch for review:
https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug32636-01&id=d95b8fa0448623bdd47b32b8b3ce60274bc3c540

The patch looked good, I merged it on master as commit d95b8fa0448623bdd47b32b8b3ce60274bc3c540. I didn't test all of the locales, but I tested a couple and they still look good.

comment:6 Changed 7 months ago by sysrqb

Keywords: tbb-backported added
Resolution: fixed
Status: needs_reviewclosed

This is d95b8fa0448623bdd47b32b8b3ce60274bc3c540 on the maint-0.2.20 branch, too.

Note: See TracTickets for help on using tickets.