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 :/
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
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.
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.
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.
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.
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.
Trac: Summary: Provide language selection dialog to Support a multi-lingual TBB that can switch between localizations Keywords: N/Adeleted, tbb-usability-stopppoint-wizard added Priority: normal to major
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).
Trac: Cc: gk, intrigeri, anonym, arthuredelstein, brade, mcs to gk, intrigeri, anonym, arthuredelstein, brade, mcs, saint
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:
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.
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?
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.
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.
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.
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.
Trac: Keywords: TorBrowserTeam201510 deleted, TorBrowserTeam201510R added Status: assigned to needs_review
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).
Next, we will work on the bundling changes (in builders/tor-browser-bundle).
Overall, this looks good. Comments:
Please use "locale" in the lang strings as well instead of "local". This is error-prone otherwise.
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.
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.
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.
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.
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.
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.
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.
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"
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?
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 (moved).
Trac: Status: needs_review to closed Resolution: N/Ato fixed