Opened 6 months ago

Closed 5 months ago

#30069 closed defect (fixed)

Security slider and about:tor strings are untranslated in Tor Browser for Android

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-mobile, tbb-8.5-must, GeorgKoppen201904, tbb-parity, TorBrowserTeam201905R
Cc: emmapeel, igt0, gk, hans@… Actual Points:
Parent ID: #26782 Points:
Reviewer: Sponsor:

Description

Even though we ship a multi-locale .apk the security slider and about:tor strings are always en-US only even though other extensions and the browser interface are properly translated.

Child Tickets

Change History (13)

comment:1 Changed 6 months ago by gk

Keywords: tbb-parity added

tbb-parity tickets

comment:2 Changed 5 months ago by sysrqb

I think this is a problem with Chrome localization, in general. about:firefox isn't localized, as well. I compared this with the current version of Fennec (66.0.2) and about:firefox shows localized text.

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

Replying to sysrqb:

I think this is a problem with Chrome localization, in general. about:firefox isn't localized, as well. I compared this with the current version of Fennec (66.0.2) and about:firefox shows localized text.

s/Chrome/system content/ maybe? In any case, not chrome. I tested this a little more, and about:firefox is localized, but it seems I needed to restart the app before it took affect (the app doesn't correctly adjust its strings after changing the system locale configuration while running). Unfortunately, about:tor and torbutton's Security Settings aren't localized.

It looks like we're missing the DTD declaration. about:firefox (in mobile/android/chrome/content/about.xhtml) use this for declaring the DTD it should use.

<!DOCTYPE html [
[snip]
<!ENTITY % fennecDTD SYSTEM "chrome://browser/locale/about.dtd">
%fennecDTD;
]>

where chrome://browser/locale/about.dtd is mobile/android/locales/en-US/chrome/about.dtd. This is documented here. This should be an easy fix :) ha.

comment:4 Changed 5 months ago by gk

If you look at the bundle the actual problem is that the resources are not properly packaged. If you e.g. look at the properties files Fennec ships by default they are available in all sorts of locales (more specifically in all those we support). However, the Torbutton resources responsible for the about:tor and security slider localization are only available in en-US. So, no matter how hard you try fixing DTD includes you won't get the missing localized files to show up. :)

So, my current plan is to do something similar to #30016 moving the missing resources to the right place (where the trick is to get "right" right). I think that should be all we need.

comment:5 Changed 5 months ago by gk

Keywords: TorBrowserTeam201904R added; TorBrowserTeam201904 removed
Status: newneeds_review

Okay, the plan in comment:4 failed but I got another one that seems to work. bug_30069 (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_30069&id=727d4502599ddb71a20891d4ec3882b9c18e3066) in my Torbutton repo has a proposed fix for review.

comment:6 Changed 5 months ago by gk

Okay, after more testing it turns out that the Torbutton strings stay in en-US by default if you are just using the systems locale as is the default setting in Fennec. Thus, even if all the other parts of the browser are correctly localized, if your system default locale is not en-US you'll have en-US strings in Torbutton related parts. Only if you are selecting your locale explicitly (even if it is in fact the same as the system locale) you'll get the properly localized strings after restart. How inconvenient.

comment:7 in reply to:  6 Changed 5 months ago by gk

Replying to gk:

Okay, after more testing it turns out that the Torbutton strings stay in en-US by default if you are just using the systems locale as is the default setting in Fennec. Thus, even if all the other parts of the browser are correctly localized, if your system default locale is not en-US you'll have en-US strings in Torbutton related parts. Only if you are selecting your locale explicitly (even if it is in fact the same as the system locale) you'll get the properly localized strings after restart. How inconvenient.

Okay, some further insights:

1) This is not a Torbutton-only problem. In fact it affects all the other extensions we bundle as well (that is HTTPS Everywhere and NoScript)

2) The problem is visible as well if I uninstall, e.g. NoScript, and then reinstall it via AMO.

3) The problem is _not_ visible if I install NoScript via AMO in a Firefox 60 ESR

4) I tried to go back in time testing older bundles. All bundles that we shipped in "multi" mode are affected at least.

2) and 3) make me believe one of our patches is interfering here. Trying to bisect...

comment:8 Changed 5 months ago by gk

comment:9 Changed 5 months ago by gk

bug_30069 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_30069&id=7e0bbadea033996f24cd8a33a3b9bf34e0beb317) in my tor-browser repo has the additional fix so that everything is localized now according to the system default locale on start-up (assuming it matches one of the locales we ship).

The key idea here was to check Mozilla's en-US .apk (they ship that in addition to a -multi one) and realizing that that one shows similar symptoms to our bundle. Decompiling both .apks and diffing the result showed the preference being set in the -multi .apk but not in the other.

While I see why we don't set that preference (we don't run the installer) I am not sure why large parts of the UI are in fact properly localized without it being set.

comment:10 Changed 5 months ago by sysrqb

Nice! Both patches look good to me, but I haven't tested them yet. I hope I'll do that tomorrow.

comment:11 Changed 5 months ago by gk

Keywords: TorBrowserTeam201905R added; TorBrowserTeam201904R removed

No April anymore, moving review tickets to May.

comment:12 Changed 5 months ago by sysrqb

Status: needs_reviewmerge_ready

Okay, after much fighting with the git submodule I finally successfully tested this. It looks good to me!

comment:13 Changed 5 months ago by gk

Resolution: fixed
Status: merge_readyclosed

Thanks. I pushed the Torbutton changes (master, commit 8877c1ecb16aec821dea8aa2282c845452cef24f) and the tor-browser ones on tor-browser-60.6.1esr-8.5-1 (commit 22d7c0ae06cbc722dae7d0f685b671ae6af25731).

FWIW: I updated the README a while back to deal with the git submodule issues when testing patches. Did you see that: https://gitweb.torproject.org/builders/tor-browser-build.git/tree/README.HACKING#n254 (please amend it if it's not sufficient).

Note: See TracTickets for help on using tickets.