Backup intl.locale.requested in 11.5.x

With multi-lingual builds we are going to make intl.locale.requested empty, to match OS locale.

However, we could use a 11.5.7 (localized) release to make it a user pref (in prefs.js).

In this way, when user will switch to the multi-lingual 12.0, they will have their preferred language saved as a user pref, and will override our new value of intl.locale.requested.

If this works as expected, users updating from 11.5.7 to 12.0 will not lose their language preference.

assigned to @pierov

mentioned in issue #41414 (closed)

marked this issue as related to #41414 (closed)

changed the description

marked this issue as related to #41378 (closed)

added Next label

@henry suggested that we try with sticky preferences.

They should be what we actually need.

If they work, we'll need to change only tor-browser-build for 11.5.x.

So, waiting for 12.0a4 to be published.

So, waiting for 12.0a4 to be published.

Actually, I've checked my test strategy already:

1. extract browser/omni.ja
2. add sticky to intl.locale.requested (single-locale at the end of defaults/preferences/000-tor-browser.js)
3. re-zip the extracted files, and replaced the original omni.ja
4. tried to launch Tor Browser, and see if TorBrowser/Data/Browser/profile.default/prefs.js contained intl.locale.requested.

It doesn't . I've tried both before and after the first launch.

But setting the pref to the same value as the default from about:config made the trick.

If they work, we'll need to change only tor-browser-build for 11.5.x.

My proposal is to call to Services.prefs.setCharPrefs("intl.locale.requested", Services.locale.requestedLocales.join(",")) in browser/components/BrowserGlue.jsm, either at each startup, or with an if that checks for Services.prefs.prefHasUserValue("intl.locale.requested").

We could take f7912211 as an example.

So, it will become a patch that has both a tor-browser and a tor-browser-build commit.

It might be better to use

Services.prefs.setStringPref("intl.locale.requested", Services.prefs.getStringPref("intl.locale.requested", ""));

since Services.locale.requestedLocale isn't necessarily the same. E.g. if the user changed the preference to "" then Services.locale.requestedLocale would be the system locale, which we don't want to save into the pref.

But in that case the pref would be a user pref already...

But yeah, it will work, too.

mentioned in issue #41378 (closed)

assigned to @dan and unassigned @pierov

The tor-browser-build change is to make intl.locale.requested sticky in projects/tor-browser/build.

For each lang we append pref("intl.locale.requested", "$lang"); to the defaults/preferences/000-tor-browser.js contained in browser/omni.ja (see line 360).

We need to change that line to pref("intl.locale.requested", "$lang", sticky);.

The change in tor-browser is to make Firefox actually write the old default to prefs.js, because making the pref sticky isn't enough.

But once you write it, it definitely works for our purpose.

added Localization Sponsor 131 FF102-esr labels

changed milestone to %Sponsor 131 - Phase 3 - Major ESR 102 Migration

I've tested the approach with a modified 12.0a3 (I've set the value manually in about:config, but we'll need to make Firefox set it to prefs.js).

mentioned in merge request !432 (merged)

mentioned in merge request tor-browser-build!570 (merged)

marked this issue as related to tor-browser-build#40672 (closed)

closed

My en-US release tor browser updated to 11.5.7 but my "intl.locale.requested" preference isn't sticky. I think "sticky" is still missing from this line https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/6d4441e082bd7c20b06071cab037b835573d877a/projects/tor-browser/build#L187 So I think it only became sticky for the non-en-US builds

reopened

@henry I think that for these cases we usually open new issues.

Also, in this case it should be in tor-browser-build.

marked this issue as related to tor-browser-build#40680 (closed)

closed