Opened 6 weeks ago

Closed 2 weeks ago

Last modified 2 weeks ago

#32365 closed defect (fixed)

Localization is broken in Tor Browser 9 on Android

Reported by: gk Owned by: sysrqb
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-9.0-issues, tbb-9.0-regression, TorBrowserTeam201911R
Cc: tbb-team Actual Points: .5
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (15)

comment:1 Changed 6 weeks ago by gk

I wonder whether this issue is actually related to #28196, but maybe not.

comment:2 in reply to:  1 ; Changed 5 weeks ago by sysrqb

Replying to gk:

I wonder whether this issue is actually related to #28196, but maybe not.

It seems all chrome content is correctly localized, but the Java strings are not localized. Hopefully there is a simple fix.

comment:3 Changed 5 weeks ago by sysrqb

Keywords: TorBrowserTeam201911 added

comment:4 in reply to:  2 ; Changed 5 weeks ago by gk

Replying to sysrqb:

Replying to gk:

I wonder whether this issue is actually related to #28196, 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.

comment:5 in reply to:  4 Changed 5 weeks ago by sysrqb

Status: newneeds_review

Replying to gk:

Replying to sysrqb:

Replying to gk:

I wonder whether this issue is actually related to #28196, 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.

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

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

comment:6 Changed 5 weeks ago by sysrqb

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.

comment:7 Changed 4 weeks ago by gk

Keywords: TorBrowserTeam201911R added; TorBrowserTeam201911 removed

comment:8 in reply to:  6 ; Changed 4 weeks ago by gk

Keywords: TorBrowserTeam201911 added; TorBrowserTeam201911R removed
Status: needs_reviewneeds_revision

Replying to sysrqb:

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.

comment:9 Changed 3 weeks ago by sysrqb

Cc: tbb-team added; sysrqb removed
Owner: changed from tbb-team to sysrqb
Status: needs_revisionassigned

comment:10 Changed 3 weeks ago by sysrqb

Status: assignedneeds_revision

comment:11 in reply to:  8 Changed 2 weeks ago by sysrqb

Replying to gk:

Replying to sysrqb:

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.

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

I opened #32628 for this.

comment:12 Changed 2 weeks ago by sysrqb

Keywords: TorBrowserTeam201911R added; TorBrowserTeam201911 removed
Status: needs_revisionneeds_review

comment:13 Changed 2 weeks ago by gk

Resolution: fixed
Status: needs_reviewclosed

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

comment:14 Changed 2 weeks ago by gk

sysrqb: please add your points.

comment:15 Changed 2 weeks ago by sysrqb

Actual Points: .5
Note: See TracTickets for help on using tickets.