441816 - Remove general.useragent.locale preference from intl.properties

Status: RESOLVED WORKSFORME

(Core :: Internationalization, defect)

Description

[Serge Gautherie (:sgautherie)]

(Noticed while looking into bug 409725 comment 7.)

Looking at
<http://mxr.mozilla.org/mozilla/search?string=general.useragent.locale&filter=%5E%5B%5E%5C0%5D*%24&tree=mozilla>
it wonder if
{{
/toolkit/locales/en-US/chrome/global/intl.properties
    * line 8 -- general.useragent.locale=en-US
/modules/libpref/src/init/all.js
    * line 52 -- pref("general.useragent.locale", "chrome://global/locale/intl.properties");
}}
could/should be removed,
as (now) |general.useragent.locale| seems to be a "regular" preference.

Comment 1

[Gordon P. Hemsley [:GPHemsley]]

I was just thinking this myself, and then I came across this four-year-old bug that seems to have fallen through the cracks.

There are a lot more references to the preference on MXR now, but I'm not sure that any of them actually do anything.

When I asked him, Axel said the following:
[18:45:58]  <GPHemsley> Pike: Do you know what general.useragent.locale is used for?
[18:47:04]  <Pike> GPHemsley: it's the value of the general.useragent.locale pref in multi-locale builds. Not sure how much that's used
[18:55:40]  <GPHemsley> I actually wonder if it's obsolete
[18:55:45]  <GPHemsley> now that I look into it
[18:58:30]  <Pike> GPHemsley: I think we're still using it for blocklist pings or something like that

Here's a more current MXR link:
http://mxr.mozilla.org/mozilla-central/search?string=general.useragent.locale

AFAIK, locales are identified essentially by their directory name. Some locales have never even changed the value of this setting, leaving it as the default 'en-US'; others have values that differ from the name of their directory (adding or removing a region subtag, for example). I don't know if those locales have suffered any detrimental effects as a result.

Also, since Gecko 5, the value of window.navigator.language has been tied to intl.accept_languages, rather than general.useragent.locale.

Are there any outstanding ties to this preference? If so, would it make more sense to tie them to the name of the directory or to intl.accept_languages?

If the preference is deemed worthwhile to keep, what would the feasibility be of having it differ strategically from the name of the directory? There are a few locales that, due to legacy, have directory names that are less than ideal, and I wonder if we could use the general.useragent.locale preference to assert what they *should* be called. (Localizers have suggested that changing the name of the directory would be burdensome, because they have the name hardcoded a number of places.)

Comment 2

[Gordon P. Hemsley [:GPHemsley]]

It seems bug 670451 is seeking to decouple search from the value of general.useragent.locale, and might be fixed as a side effect of fixing the related bug 670450.

Comment 3

[Axel Hecht [:Pike]]

I'm not convinced that the bugs 670450 and 670451 should be fixed, at least not like the reporter wants. We shouldn't take those for granted, at least.

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

we don't have general.useragent.locale anymore. Closing. Reopen if needed.