265400 - OS language should be added to language settings (intl.accept_languages) automatically

Status: NEW

(Core :: Internationalization, enhancement)

Description

[Matej Skubic]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

When you install Firefox default language settings are set to en-us and en.
They should be set from OS regional settings

Reproducible: Always
Steps to Reproduce:
1. install firefox
2. run firefox
3. tools - options - general - languages

Actual Results:  
en-us
en

Expected Results:  
la - language from regional settings

Comment 1

[Steffen Wilberg]

-> OS Integration and confirming.

Comment 2

[O. Atsushi (Torisugari)]

Maybe system charset suggested by nsIPlatformCharset as well?

Comment 3

[Jo Hermans]

*** Bug 238034 has been marked as a duplicate of this bug. ***

Comment 4

[O. Atsushi (Torisugari)]

As far as I know, "OS Integration" part has already been
implemented as nsILocaleService::getSystemLocale().

e.g.
>var localeService =
>  Components.classes["@mozilla.org/intl/nslocaleservice;1"]
>            .getService(Components.interfaces.nsILocaleService);
>var locale = localeService.getSystemLocale();
>
>var localeName = locale.getCategory("NSILOCALE_MESSAGES");
>Components.utils.reportError(localeName);

Then, probably the proper component is either netlib or pref settings,
because this bug is an issue about "intl.accept_language" and only
HTTP handler uses the pref value.

Comment 5

[Robert Strong (they/them - no direct email)]

Not a shell integration bug. I suspect this is a Firefox -> General bug but moving to untriaged in the hope that it gets triaged to the correct component

Comment 6

[Olivia Hall [:olivia]]

Hi Makoto,

I'm trying to learn more about intl.accept_languages for Android and the impact on translations.

So, right now, in Android, if I add multiple preferred languages on the OS screen, I will get all of the language codes listed there of preferred languages: e.g., OS languages: 1. English, 2. German, 3. French = en-US,de-DE,fr-FR. (Tested in 125 Nightly.)

However, testing adding additional preferred OS languages in Windows 11, 125 Release, and additional preferred OS languages in MacOS 14.2.1, 125 Release, do not show up in intl.accept_languages on those platforms.

Should Windows and MacOS also automatically pick up these languages from the OS?

Should Android not, due to potential fingerprinting?

The reason this bug is interesting is for the new translations feature.

So, for translations, we try to determine if the user "knows" a language, and intl.accept_languages is one of the ways we determine if the user may know the language.

In Android it causes the behavior as described in Bug 1884694 comment 6. In Desktop, because the behavior is different, this multiple language scenario occurs differently.

Curious to know your thoughts and what your recommendation is!

Comment 7

[Makoto Kato [:m_kato]]

(In reply to Olivia Hall [:olivia] from comment #6)

Hi Makoto,

I'm trying to learn more about intl.accept_languages for Android and the impact on translations.

So, right now, in Android, if I add multiple preferred languages on the OS screen, I will get all of the language codes listed there of preferred languages: e.g., OS languages: 1. English, 2. German, 3. French = en-US,de-DE,fr-FR. (Tested in 125 Nightly.)

However, testing adding additional preferred OS languages in Windows 11, 125 Release, and additional preferred OS languages in MacOS 14.2.1, 125 Release, do not show up in intl.accept_languages on those platforms.

Should Windows and MacOS also automatically pick up these languages from the OS?

No, we shouldn't pick up it. Actually, this value is set by localizer team. Example, Spanish/Spain uses "intl.accept_languages = es-ES, es, en-US, en".

Since Fenix/GeckoView has multi-locale package, we have auto-detection setting from OS.

Should Android not, due to potential fingerprinting?

I am not sure, but this behavior is whether multi-locale or single-locale package. When Fennec (old Firefox Android) makes multi-locale, we decide this behavior. But when setting locale by user, not using auto-detection, its behavior may be different on Fennec era. I will re-check it.

The reason this bug is interesting is for the new translations feature.

So, for translations, we try to determine if the user "knows" a language, and intl.accept_languages is one of the ways we determine if the user may know the language.

In Android it causes the behavior as described in Bug 1884694 comment 6. In Desktop, because the behavior is different, this multiple language scenario occurs differently.

Curious to know your thoughts and what your recommendation is!

Fenix may call GeckoRuntimeSettings.setLocales, so we have to consider too if translation uses accept-language.