Closed Bug 1413866 Opened 7 years ago Closed 7 years ago

Pref intl.locale.MatchOS not working as expected on Windows OS

Categories

(Core :: Internationalization, defect, P2)

Product:
Core
Component:
Internationalization
Version:
57 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: heim, Assigned: zbraniecki)

References

(
URL
)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171002220106

Steps to reproduce:

If i set the pref intl.locale.MatchOS to true, one would expect, that FF starts in the language, that the Windows Profile is started in. If the following conditions are met: Firefox is installed in en-US and the necessary language pack is installed as an extension either globally or locally.


Actual results:

There are no consistent results.
In the past  (years ago), FF was following regional or keyboard settings.
Actual test with Windows 10 (1607) x64 en-US with MUI installed for german, french and italian with Firefox 57 latest beta and language packs for de/it/fr installed globally in "C:\Program Files\Mozilla Firefox\browser\extensions".
If i set the Windows MUI to german and FF intl.locale.MatchOS to true, sometimes it switches to german, sometimes not.
If i set the Windows MUI language to it or fr nothing happens at all!
Tests on OSX show, that this is working reliable on this platform.
Because this has never really worked, i put together the extension "Locale2MUI" years ago. In there one can see the things to rely on for this to work.


Expected results:

In a multi-language environment, this is essential in FF57, as all the language switching extensions wont function anymore!
Hi Niklaus,

Thank you for filing this bug report.

Can you provide more details for the step: `If i set the Windows MUI language (...)` ?

We're currently using the locale name on Windows. I'm not sure how it overlaps with MUI language and knowing how to set it in Windows myself (do I need a multi-user setup for that?) would help me investigate further.


[0] http://searchfox.org/mozilla-central/source/intl/locale/windows/OSPreferences_win.cpp#21
Flags: needinfo?(heim)
Mike - have you encountered such issues with multi-user setups?
Flags: needinfo?(mozilla)
Here's an extension the reporter linked for me that he wrote to make the setup work: https://addons.mozilla.org/en-US/firefox/addon/locale2mui/
URL: https://addons.mozilla.org/en-US/fire...
This may be related to our plan to improve our hooks into the Windows API as per bug 1337067 comment 6.

My first hypothesis is that we take the "OSPreferences::SystemLocale" from Windows using pretty old API and we retrieve what's called "user locale".

Maybe the setup Niklaus describes uses some other locale setting from Windows that doesn't translate over to user locale?
Component: Untriaged → Internationalization
Product: Firefox → Core
I haven't heard of this issue, but I think it should be straightforward to reproduce

The trick is to add the language bar

http://www.thewindowsclub.com/multilingual-user-interface-mui-windows

So you can switch on the fly.

I guess we need to figure out what is actually changes via the language bar and make sure we are reading that?
Flags: needinfo?(mozilla)
Hi Mike,
maybe this part of the Problem. There is no switching of the UI-language with the language bar.
But everythin else like Region, format of the date, keyboard aso.
Here is the way to go:
https://www.howtogeek.com/232659/how-to-change-the-display-language-in-windows-10/
Don't know the API-call you need to get the right language.
In my extension, i used the regkey, which reflect the MUI-language.

Best regards,
Nick
Flags: needinfo?(heim)
Thank you!

Here are the Steps to Reproduce that I collected so far:


1) Install Firefox en-US 57 in Windows 10
2) Install de, fr and it language packs for said Firefox 57
3) Following [0] set the Windows Display Language to one of: "de", "it", or "fr"
4) Log out and log back in to Windows
5) In Firefox set `intl.locale.matchOS` to true
6) Restart Firefox

Expected result:

Firefox follows Windows Display Language

Current result:

Firefox is using en-US locale

====

[0] https://www.howtogeek.com/232659/how-to-change-the-display-language-in-windows-10/


Niklaus - can you confirm that those are correct STR? In particular, there's a difference between "User Locale" (used for formatting date/time etc.) and Display Locale (used to translate Windows) and there's a third thing called "App Locale" (which is what is used to localize Windows Apps, not Windows itself) - I'd like to make sure that I'm testing the right setting.

In the link you provided, the tutorial guides through setting the Display Locale by adding a language and clicking on "Set as default". Is that how your workstations language is set?
Flags: needinfo?(heim)
Assignee: nobody → gandalf
Hi Zibi,
yes, this is the manual way to do it.
But you could do it by Group Policy also (and by other ways).
This behaviour was introduced back in the XP-days.
But since Vista, it is the standard way of adding more languages to Windows.

the API-Call to get it, is: 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318139(v=vs.85).aspx

A quick search through searchfox produced no show ups to this API.

Best regards,
Nick
Flags: needinfo?(heim)
Depends on: 1414186
Status: UNCONFIRMED → NEW
Ever confirmed: true
I was able to confirm the issue.

The current behavior of Firefox is to follow what's called `LOCALE_SYSTEM_DEFAULT` which is an old variable that is currently buried deep in the Windows UI.

In order to change it, one must go to Settings>Time&Date>Additional Settings>Region>Administration>Change System Regional Settings.

In bug 1414186 I introduced a patch that changes our behavior to look for what's called "Display Language" in Windows which is the language setting described in https://msdn.microsoft.com/en-us/library/windows/desktop/dd318139(v=vs.85).aspx


It's a fairly simple change that should be safe to land, but I'm not sure if we'll be able to backport it to beta, and I seriously doubt it'll be accepted for 57 stable.

For that reason, I'll keep that in the separate bug and here we can investigate other ways to help Niklaus.
:mkaply pointed out to nsAutoConfig feature [0] which he thinks might be used to provide the functionality that the extension provided before.


[0] https://mike.kaply.com/2012/03/22/customizing-firefox-advanced-autoconfig-files/
Niklaus - can you take a look at the AutoConfig and see if it looks like a potential solution for you until we get the proper fix?
Flags: needinfo?(heim)
Hi folks,
i use AutoConfig in our setup trough CCK2 from Mike, which is a big, big help in rolling out tailored versions of FF.
BUT: How should i read the Language out of the OS, with everything truncated away and locked down in FF57?
AND: AutoConfig could have had the Java-Script of my extension and run it in pre FF57 versions. How should it be possible, to read the OS Language, change the "general.useragent.locale" pref and initiate a restart on the fly?

Maybe you folks see a way...

Best regards, Nick
Flags: needinfo?(heim)
Nick - I got the patch in bug 1414186 landed on master. That means that this will be fixed in 58 definitely. I also nominated it to be uplifted for 57 due to impact on multilingual mass deployments like yours. If we're successful, maybe we won't need AutoConfig script!

I expect to know more by EOD Monday PST time.
Hi Zibi,
does that mean, that the patch is already in the nightly builds of the FF58 branch?
If yes, i could test it immediately.
Best regards,
Nick
Nick: Yes, latest Nightly builds have the patch, so testing would be much appreciated - thanks!
Hi folks,
tested FF58 nightly on Saturday. Didn't work.
Today, i fired the Nightly branch again. It did the automatic update.
AND: Bingo, it works now.
Tested with:
Windows 10 x64 en-US CBB (Current Branch for Business) v1709 with language packs for de-DE, fr-FR, it-IT
And 
Windows 7 x86 en-US Enterprise SP1 with language packs for de-DE, fr-FR, it-IT

That will be a real big help in our deployment.

Nick
Priority: -- → P2
Hi Zibi,
can i we expect, that this fix will make it into the FF57 branch?
Otherwise, i do not have a chance to roll-out FF57.
Thanks,
Nick
(In reply to Nick Heim from comment #16)
> Hi Zibi,
> can i we expect, that this fix will make it into the FF57 branch?

Yes! This fix landed in time for Fx 57.0rc1 as per bug 1414186 comment 23.

Can you verify that it works for you?
Flags: needinfo?(heim)
Hi Zibi,
a quick test today on FF57 RC1 x64 en-US looked very promising.
Tested with:
Windows 10 x64 en-US CBB (Current Branch for Business) v1709 with language packs for de-DE, fr-FR, it-IT.
FF language packs in %ProgramFiles%\Mozilla Firefox\browser\extensions (de.xpi, fr.xpi, it.xpi).
Set intl.locale.MatchOS to true
Switched the OS to German, Italian, French and English and every time FF switched to the OS-Language and worked as expected.

Thank you very much for your quick, reliable work.

Nick
Flags: needinfo?(heim)
Thank you Nick for reporting it and working with us through the process of fixing it!

I'm going to close this bug as fixed. If you encounter this problem again, please reopen and we'll investigate.

Also, if you encounter other bugs, please, file them as early as possible :)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I wonder if the changes made due to this bug are related, but I noticed that suddenly this is not working anymore for me in MacOS, with Firefox 59.02 and MacOS 10.12.6. Unlike in reporter's case, for me this still worked in Firefox 57.

I'll try to find time to file a separate report at some point.
(In reply to plj from comment #20)
> I wonder if the changes made due to this bug are related, but I noticed that
> suddenly this is not working anymore for me in MacOS, with Firefox 59.02 and
> MacOS 10.12.6. Unlike in reporter's case, for me this still worked in
> Firefox 57.

Locale prefs have changed, see bug 1414390; this may be what you're seeing. In short, general.useragent.locale is gone; use intl.locale.requested instead. And intl.locale.MatchOS is gone, replaced by setting intl.locale.requested to an empty string.

If that doesn't explain your case, filing a separate report would be the best way forward.
Thank you Jonathan, that explains it perfectly! It works now again; I had just missed the prefs change.
You need to log in before you can comment on or make changes to this bug.