Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#12967 closed enhancement (fixed)

Support a multi-lingual TBB that can switch between localizations

Reported by: mikeperry Owned by: mcs
Priority: High Milestone:
Component: Applications/Tor Launcher Version:
Severity: Normal Keywords: tbb-usability-stopppoint-wizard, TorBrowserTeam201510R
Cc: gk, intrigeri, anonym, arthuredelstein, brade, mcs, saint Actual Points:
Parent ID: #17304 Points:
Reviewer: Sponsor: SponsorU

Description

I think for our hardened and/or alpha series, we should just include all of our langpacks in one release, and ask the user for their language. The pref general.useragent.locale exists for this purpose.

The reason we want to do this is to avoid another 2G worth of dist files for the hardened series (which will also need special build options, like 64 bit on Windows and Mac).

This is probably a usability sinkhole, though :/

Child Tickets

Attachments (1)

localePicker.png (59.4 KB) - added by mcs 4 years ago.
locale picker screenshot (work in progress)

Download all attachments as: .zip

Change History (35)

comment:1 Changed 5 years ago by intrigeri

My 2 cts: providing a dist that contains all locales data, especially if this was done for the stable series too, would remove one of the stumbling blocks for Tails to use the Tor Browser binary instead of crafting our own. And, by the way, once it's done this way, perhaps more languages could be supported than the handful that get their dedicated dist currently.

comment:2 Changed 5 years ago by intrigeri

Cc: intrigeri anonym added

comment:3 Changed 5 years ago by mikeperry

intrigeri: Good point. Though I assume that Tails would not be using our alpha series. Would tails be interested in using a separate hardened (but ~2X slower and 2X more memory) stable series?

I don't think this language selection dialog should display in our normal stable series. I think per-language downloads is the right thing to do for that. But you could always turn it on and add in more langpacks.

comment:4 in reply to:  3 Changed 5 years ago by intrigeri

Replying to mikeperry:

Though I assume that Tails would not be using our alpha series.

Right.

Would tails be interested in using a separate hardened (but ~2X slower and 2X more memory) stable series?

Most likely yes. The hardening is supposed to land into stable at some point anyway, so we'll have to cope with the slowness and increased memory usage at some point anyway, right? If so, then dealing with it earlier is not necessarily a problem for us.

I don't think this language selection dialog should display in our normal stable series.

OK. But I wonder why a dialog is actually needed, as opposed to simply respect the OS' default locales settings, and optionally offering a way (command-line switch?) to run Tor Browser with a different language.

I think per-language downloads is the right thing to do for that. But you could always turn it on and add in more langpacks.

For the Tails usecase, I think the best thing would be:

  • have a stable tarball with all laguage packs in (hardened or not);
  • don't use the language selection dialog;
  • respect the OS' locales settings (that the user has chosen in Tails Greeter).

Note that we still haven't decided whether we'll try to switch to the Tor Browser binaries for Tails 1.2 (October 14). It's now a bit late to start working on it, but who knows. It partly depends on how much work we have to do to have a Tor Browser tarball that suits our needs (as described above). Of course, I'm aware that the TBB team is even more swamped than usual this month, "thanks" to the migration to FF31 ESR, so it mostly depends on how much time we (Tails folks) can put into adapting the TBB build system for our needs.

comment:5 Changed 5 years ago by hellais

Why is it required to have the user choose the language of the browser when it starts?

Would it not be possible to detect the language of the operating system and start the browser in that language?

I believe this is what most pieces of software do.

comment:6 in reply to:  5 Changed 5 years ago by gk

Replying to hellais:

Why is it required to have the user choose the language of the browser when it starts?

Would it not be possible to detect the language of the operating system and start the browser in that language?

I believe this is what most pieces of software do.

Maybe they do. But that does not mean it is a good thing to do. Keep in mind Mozilla is not doing it ,and for a reason I think, given that localized bundles are much more expensive resource-wise. Anyway, there are a bunch of other things that make me skeptical here: https://lists.torproject.org/pipermail/tor-talk/2014-September/034745.html.

comment:7 Changed 5 years ago by mikeperry

Keywords: tbb-usability-stopppoint-wizard added
Priority: normalmajor
Summary: Provide language selection dialogSupport a multi-lingual TBB that can switch between localizations

I am going to cheat a little bit and call this a usability stoppoint: For censored users, it may be hard enough to find *any* TBB, let alone one in their language.

I think Goerg is right that there may be users for which their desktop is not in the right locale, but really need to use TBB in the locale of their choice (think travelers who just wandered into a censored, foreign Internet cafe and really need to get to their email/twitter/facebook in an emergency). However, I also see the benefit of a clear dropdown language selection dialog *in the current OS locale* for such users to choose their language.

If we can somehow merge a localized, translated locale choice with the current "Censored vs noncensored" dialog window, I think we have ourselves a winner on a lot of axis. Even if this means restarting the browser quickly if that locale is changed..

Regardless of the UI though, shipping a bundle with some kind of capability to display its UI in *any* locale is still a win in terms of helping more people use TBB.

comment:8 Changed 5 years ago by gk

Owner: changed from brade to gk
Status: newassigned

comment:9 Changed 4 years ago by arthuredelstein

Cc: arthuredelstein added

comment:10 Changed 4 years ago by mcs

Cc: brade mcs added

comment:11 Changed 4 years ago by saint

Cc: saint added

This would make the job of redistributing Tor to users and trainers much easier, as well. It would also reduce the amount of software that I'd need to make available and verification strings for them (currently 60 per Tor Browser release - 4 would be a major improvement).

comment:12 Changed 4 years ago by gk

Keywords: TorBrowserTeam201510 added
Owner: changed from gk to mcs
Sponsor: SponsorU

Changed 4 years ago by mcs

Attachment: localePicker.png added

locale picker screenshot (work in progress)

comment:13 Changed 4 years ago by mcs

Kathy and I are actively working on this ticket. We propose that a new "locale picker" dialog be presented once the first time the browser is opened. Here is what our work-in-progress dialog looks like:

locale picker screenshot (work in progress)

Each language name will be displayed in its own language. The other portions of this prompt dialog will be presented using the OS language (for example, the "Please select a language" prompt will be localized and displayed in French on a French system). And the default choice for language will be set to match the OS language setting.

Feedback is welcome.

comment:14 in reply to:  13 ; Changed 4 years ago by anonym

Replying to mcs:

Kathy and I are actively working on this ticket. We propose that a new "locale picker" dialog be presented once the first time the browser is opened.

It looks very nice!

From Tails side, users will pick a locale when starting Tails, so we need a way to not show the locale picker and instead use the system locale. I assume that all we have to do is set some first-run pref to not show it, and then set general.useragent.locale properly (or intl.locale.matchOS?) and then we'll have the same result as if the user used your locale picker. Am I correct?

comment:15 in reply to:  14 Changed 4 years ago by mcs

Replying to anonym:

From Tails side, users will pick a locale when starting Tails, so we need a way to not show the locale picker and instead use the system locale. I assume that all we have to do is set some first-run pref to not show it, and then set general.useragent.locale properly (or intl.locale.matchOS?) and then we'll have the same result as if the user used your locale picker. Am I correct?

Yes. We plan to support a TOR_SKIP_LOCALE_PROMPT env variable as well as a hidden pref. Our plan is for Tor Browser to have (via Tor Launcher) intl.locale.matchOS = true. When the user answers the locale prompt, the Tor Launcher code will reset intl.locale.matchOS to false and also set general.useragent.locale to the locale that was chosen.

comment:16 Changed 4 years ago by gk

Parent ID: #17304

comment:17 Changed 4 years ago by gk

I think this is fine for the alpha series at least.

comment:18 Changed 4 years ago by mcs

The changes for part 1 (Tor Launcher) are available here:
https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug12967-01&id=6125fd9230ce1bd542fd502dcc25cbc3a15782a1

Next, we will work on the bundling changes (in builders/tor-browser-bundle).

comment:19 Changed 4 years ago by mcs

gk and others: While contemplating the bundling/packaging portion of this ticket, Kathy and I remembered a question we thought of a while ago: Should all of these changes be conditional so we can easily switch between creating multi-lingual packages and our traditional locale-specific packages?

We think the answer is "yes", especially on the builders/tor-browser-bundle side (we can easily branch Tor Launcher if we want to exclude the language prompt there). So maybe we will include something in versions.alpha such as MULTI_LINGUAL=1 to turn on the new behavior, or perhaps the opposite is better, e.g., ONE_PACKAGE_PER_LOCALE=1 to restore the old behavior.

comment:20 in reply to:  19 Changed 4 years ago by gk

Replying to mcs:

gk and others: While contemplating the bundling/packaging portion of this ticket, Kathy and I remembered a question we thought of a while ago: Should all of these changes be conditional so we can easily switch between creating multi-lingual packages and our traditional locale-specific packages?

We think the answer is "yes", especially on the builders/tor-browser-bundle side (we can easily branch Tor Launcher if we want to exclude the language prompt there). So maybe we will include something in versions.alpha such as MULTI_LINGUAL=1 to turn on the new behavior, or perhaps the opposite is better, e.g., ONE_PACKAGE_PER_LOCALE=1 to restore the old behavior.

Yes, having some env variable allowing us to switch easily is a good idea. I am a fan of MULTI_LINGUAL I think. It would work like BUILD_PT_BUNDLES which is indicating our PT support and set to 1 as the default new behavior.

comment:21 Changed 4 years ago by mcs

Keywords: TorBrowserTeam201510R added; TorBrowserTeam201510 removed
Status: assignedneeds_review

The "builder" changes are here:
https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/commit/?h=bug12967-01&id=6e1ecb2662b2cbcd6e4f1ee4635ca8fc4924c387

Please review (using -w makes for much smaller diffs). Feedback is welcome, especially for the way Kathy and I use "ALL" as a locale within the package filenames and when fetching the update manifests. I think it is a good solution, but someone else may have a better idea.

comment:22 Changed 4 years ago by mcs

I forgot to mention that we did not include a switch to a new Tor Launcher in the "builder" diffs; that is something we will need to do once we have updated translations (in the Tor Launcher changes, we added two entities to support the new language prompt).

comment:23 Changed 4 years ago by mcs

I filed a related ticket: #17341

comment:24 in reply to:  18 ; Changed 4 years ago by gk

Severity: Normal
Status: needs_reviewneeds_revision

Replying to mcs:

The changes for part 1 (Tor Launcher) are available here:
https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug12967-01&id=6125fd9230ce1bd542fd502dcc25cbc3a15782a1

Next, we will work on the bundling changes (in builders/tor-browser-bundle).

Overall, this looks good. Comments:

1) Please use "locale" in the lang strings as well instead of "local". This is error-prone otherwise.

2) If I test your changes on a non-english system (in this case a german one) the "Quit" button and the "Next" button are shown using different locales (the former is translated the latter in english) which is confusing.

3) While it seems my non-en locale is detected the selected language on the wizard is english, though.
It seemed to me, while reading initLocaleDialog(), it should be "Deutsch" in my case.

4)

+<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

has a superfluous whitespace at the end.

comment:25 in reply to:  24 Changed 4 years ago by gk

Replying to gk:

2) If I test your changes on a non-english system (in this case a german one) the "Quit" button and the "Next" button are shown using different locales (the former is translated the latter in english) which is confusing.

3) While it seems my non-en locale is detected the selected language on the wizard is english, though.

That was actually my fault as I used a plain en-US bundle and forgot to copy the german lang pack over.

comment:26 Changed 4 years ago by mcs

Status: needs_revisionneeds_review

Here is a revised patch that addresses issues 1) and 4) from comment:24. We also added an ondblclick handler to the language list which sets the language and auto-advances to the network setup wizard. Please review.

comment:27 Changed 4 years ago by mcs

Following gk's suggestion, I just created a maint-0.2.7 branch within the tor-launcher repo (based at the 0.2.7.7 tag). The changes for this ticket will go on master and we will want to use the maint-0.2.7 branch for our stable releases.

comment:28 in reply to:  26 Changed 4 years ago by gk

Replying to mcs:

Here is a revised patch that addresses issues 1) and 4) from comment:24. We also added an ondblclick handler to the language list which sets the language and auto-advances to the network setup wizard. Please review.

I tested a bit more and it looks good to me, thanks! This is commit 919ccb92304fe86bda1d11ad6758871ccd483185.

comment:29 in reply to:  21 ; Changed 4 years ago by gk

Replying to mcs:

The "builder" changes are here:
https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/commit/?h=bug12967-01&id=6e1ecb2662b2cbcd6e4f1ee4635ca8fc4924c387

Please review (using -w makes for much smaller diffs). Feedback is welcome, especially for the way Kathy and I use "ALL" as a locale within the package filenames and when fetching the update manifests. I think it is a good solution, but someone else may have a better idea.

This looks good. Some things I have:

What about "generic"? Or what about "" (like tor-browser-linux64-5.5a4.tar.xz) given that we only include the locales in the package names as we ship differently localized bundles. If that is not done anymore not confusing the user with either "ALL" or "generic" or ... might be a good option?

I think we should do the changes to the versions.nightly first. If the patches stick in a nightly build we can use them for versions.alpha etc. as soon as we tag a tor-launcher version.

It appears to me we only need one cd mac-langpacks/cd win32-langpacks/cd linux-langpacks if we move them at the beginning of the respective for-loop?

s/package names/package name/ (there is just one package with all locales)

Linux only:

"packages" -> "package" (we plan to create only one)
whitespace between "popd" and "Set the update.locale"

Last edited 4 years ago by gk (previous) (diff)

comment:30 Changed 4 years ago by gk

Status: needs_reviewneeds_revision

comment:31 in reply to:  29 Changed 4 years ago by mcs

Replying to gk:

What about "generic"? Or what about "" (like tor-browser-linux64-5.5a4.tar.xz) given that we only include the locales in the package names as we ship differently localized bundles. If that is not done anymore not confusing the user with either "ALL" or "generic" or ... might be a good option?

Kathy really does not like "generic". She suggests we use "multi" instead. And once we stop shipping the locale-specific packages we should remove -multi from the download file names (but keep it internally as the update locale). If it is important to avoid "multi" or another non-empty string for update.locale then we will need to do more work.

I think we should do the changes to the versions.nightly first. If the patches stick in a nightly build we can use them for versions.alpha etc. as soon as we tag a tor-launcher version.

OK; we will fix this when we revise the patch.

It appears to me we only need one cd mac-langpacks/cd win32-langpacks/cd linux-langpacks if we move them at the beginning of the respective for-loop?

Looking at it some more, it seems better to avoid those cd's entirely. We are going to try this in our revised patch.

s/package names/package name/ (there is just one package with all locales)

We will fix this.

Linux only:

"packages" -> "package" (we plan to create only one)

We will also fix this.

whitespace between "popd" and "Set the update.locale"

I am not sure about this. In most places the gitian-bundle.yml scripts avoid blank lines but there are some places where blank lines are used (e.g., within the for loop where the locale-specific packages are created). I personally prefer some blank lines because it makes navigation easier within my editor, but it is not a big deal. It seems like we should either try to use blank lines more or avoid them entirely. Which do you prefer?

comment:32 Changed 4 years ago by mcs

Status: needs_revisionneeds_review

Per IRC, we are going to stick with "ALL" for now. A revised patch is available here:

https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/commit/?h=bug12967-02&id=10a8f2badf8294d8a69d9898fee805750789da86

Please review.

comment:33 Changed 4 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

I think we are done here, thanks! I merged this as commit 919ccb92304fe86bda1d11ad6758871ccd483185 into tor-launcher master. For ideas on how to deploy that beyond the nightlies and the hardened build series, I created #17400.

comment:34 Changed 4 years ago by mcs

#17344 covers a desirable future enhancement (noted here so people can find it from this ticket).

Note: See TracTickets for help on using tickets.