Take a Tor Browser 8.5.6 on an Android system in locale foo (foo != en-US and foo is a locale we actually ship).
If you start Tor Browser for the first (and subsequent) times on that system you see e.g. the connect button in locale foo and the onboarding in locale foo, the whole browser UI in locale foo, and about:tor in locale foo.
Now, remove 8.5.6 and install 9.0 or 9.0.1 (I actually just tested with 9.0.1 but remember vaguely seeing this weirdness when testing 9.0aX builds even though I did not put 1 and 1 together back then :( ).
If you start Tor Browser for the first (and subsequent) times on that system you see e.g. the connect button in en-US and the onboarding in en-US and the browser UI in en-US. However, Torbutton related things like the slider and about:tor are still shown in locale foo
This bug has the nasty consquence, I think, that the locale for the donation campaign is not properly detected. Instead, just the default link is used.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
I wonder whether this issue is actually related to legacy/trac#28196 (moved), but maybe not.
It seems all chrome content is correctly localized, but the Java strings are not localized. Hopefully there is a simple fix.
I wonder whether this issue is actually related to legacy/trac#28196 (moved), but maybe not.
It seems all chrome content is correctly localized, but the Java strings are not localized. Hopefully there is a simple fix.
Not sure if you are seeing the same bug as I but for me essentially the whole browser chrome is not localized. The exception here is UI coming from Torbutton which is localized. So, e.g. the whole Settings menu items are only in English.
I wonder whether this issue is actually related to legacy/trac#28196 (moved), but maybe not.
It seems all chrome content is correctly localized, but the Java strings are not localized. Hopefully there is a simple fix.
Not sure if you are seeing the same bug as I but for me essentially the whole browser chrome is not localized. The exception here is UI coming from Torbutton which is localized. So, e.g. the whole Settings menu items are only in English.
Right, sorry, "chrome" wasn't the correct description. I should've said something like "privileged-chrome content". For example, about:firefox is correctly localized, but I see the menu and and preferences are not localized.
It seems the reason for this is Mozilla changed how they create multi-locale packages. We have two options.
I have a patch for this in my tor-browser-build repo, bug32365_00.Unfortunately, the firefox build is broken using this method because apparently we broke ./mach android archive-geckoview, and this is called as the final step in ./mach package-multi-locale. I created a tor-browser patch that comments-out calling ./mach android archive-geckoview, as a workaround.
Another alternative is we re-implement ./mach package-multi-locale in the firefox build file. It is relatively straight-forward, see package_l10n in python/mozbuild/mozbuild/mach_commands.py. I have another branch with only this tor-browser-build patch, bug32365_01.
Considering option (2) is a small change, that seems like the better solution. I'm building a small variant of (2) now, as well - using ./mach package instead of make package. It's possible ./mach android assemble-app is the only missing piece.
Okay, i think option (3) is the more simple. We only need ./mach android assemble-app. I also filtered mk from the locale list. Branch bug32365_02.
Thanks! I assume the change got introduced in https://bugzilla.mozilla.org/show_bug.cgi?id=1443208 and looking at that bug your patch looks good. However, I don't think we should filter mk as you do. If we do the filtering no mk content is shown. But if we don't do it then at least the Torbutton parts (like the about:tor page) are localized if you have an mk device. I'd argue that is a win. We probably should put a comment above the part where you filtered mk as this behavior is not obvious.
What bothers me is that the locale is still not properly propagated to our about:tor page and fundraising parts. It's just the default link that's visible unless you switch the locale. But then after restart you see the same again. We should file a ticket for that and get this fixed for the next release.
Trac: Status: needs_review to needs_revision Keywords: TorBrowserTeam201911R deleted, TorBrowserTeam201911 added
Okay, i think option (3) is the more simple. We only need ./mach android assemble-app. I also filtered mk from the locale list. Branch bug32365_02.
Thanks! I assume the change got introduced in https://bugzilla.mozilla.org/show_bug.cgi?id=1443208 and looking at that bug your patch looks good. However, I don't think we should filter mk as you do. If we do the filtering no mk content is shown. But if we don't do it then at least the Torbutton parts (like the about:tor page) are localized if you have an mk device. I'd argue that is a win. We probably should put a comment above the part where you filtered mk as this behavior is not obvious.
That makes sense. I created a new branch reflecting these changes. bug32365_03
What bothers me is that the locale is still not properly propagated to our about:tor page and fundraising parts. It's just the default link that's visible unless you switch the locale. But then after restart you see the same again. We should file a ticket for that and get this fixed for the next release.
I debugged this. It is cause by two problems.
In aboutTor-content.js:onPageLoad we only track changes of intl.locale.os, however, in Fennec the locale may be set by either intl.locale.os or intl.locale.requested.
When about:tor is loaded, onLocaleChange is called before onChromeDataUpdate, therefore the content.document.body.getAttribute("mobile") conditional in onLocaleChange is always undefined at the first page load.
Thanks. I fixed a typo in the comment (to avoid another round-trip) and picked the fix onto master (commit 4f97d497ea11a8325cafeaec6ac51fb10ef56de1) and maint-9.0 (commit 54091ab8d4a431458105d2be5346ac5232fea265). It should be available in 9.5a3 and 9.0.2
Trac: Status: needs_review to closed Resolution: N/Ato fixed