1325751 - Firefox ignores user chosen regional settings in date/time display after bug 1301640

Status: RESOLVED DUPLICATE of bug 1308329

(Core :: Internationalization, defect, P3)

Description

[Jorg K (CEST = GMT+2)]

+++ This bug was initially created as a clone of Bug #1301640 +++

Take any web page and display the page info.

Before bug 1301640:
Modified: Tuesday, 31 May 2016 22:29:56
This is obeying the user chosen date/time format which is *not* matching the application local of FF used here (en-US).

Now:
Modified: May 31, 2016, 10:29:56 PM
This ignores the user chosen date/time format and enforces en-US.

This is really unacceptable.

I don't know whether platforms other than Windows are also affected.

Comment 1

[Jorg K (CEST = GMT+2)]

Hmm, this bug is worse then I thought. I was under the impression that following bug 1301640 ICU would use the system locale to get the date/time format while ignoring any user configuration, at least on Windows.

That doesn't seem to be the case. I changed the system locale on Windows 7 from English/US to English/AU to English/GB to German/DE and I still get the very same time display with "am" and "pm". So it must be using the application locale. That's really no good since may people use the en-US version of FF and have it use the user's configuration. That would be true for all users in India, for example. Let the telemetry guys confirm that en-US is used 99% in India, however, India being a Commonwealth country, they don't use the US formats.

Comment 2

[Jorg K (CEST = GMT+2)]

Note that bug 1301640 has been backed out for now:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a6882a49e907bd01ab7b782a0985614f4565e02e

Comment 3

[Magnus Melin [:mkmelin]]

Agreed it's totally unacceptable 

Bug 1308329 seems intended to create some facility to support this.

Comment 4

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

> Hmm, this bug is worse then I thought. I was under the impression that following bug 1301640 ICU would use the system locale to get the date/time format while ignoring any user configuration, at least on Windows.

ICU uses CLDR for retrieving locale's date/time. And we aim to not use system locale, but browser locale.

The browser locale follow's system locale, until manually changed.

> That's really no good since may people use the en-US version of FF and have it use the user's configuration.

I disagree. If your application has locale settings, your intl should follow them. For every case like yours ("I want my app to ignore my apps locale!") there are people who'll say the opposite ("I changed my browser's locale and it still follows my OS locale!").

Every fix to a bug breaks someone's workflow - https://xkcd.com/1172/ ;)

> That would be true for all users in India, for example. Let the telemetry guys confirm that en-US is used 99% in India, however, India being a Commonwealth country, they don't use the US formats.

So, do you happen to know what users in India do in that case? Because you're not removing the problem with your approach, you just push it up the stream. Do they select en-US and then manually modify date, time and number settings? Each one of them manually? :)

I'd expect there to be some sort of en-IN, with the right defaults for the region, and lo-and-behold, that's exactly what CLDR provides:

http://cldr.unicode.org/development/development-process/design-proposals/english-inheritance

Comment 5

[Jorg K (CEST = GMT+2)]

I grabbed a copy of FF with the change from bug 1301640 included, so I can experiment. Just a few questions.

What is browser locale? The locale that's compiled into the binary? What about pref general.useragent.locale?

> The browser locale follow's system locale, until manually changed.
Please explain. I'm on Windows, so there is limited scope in changing the "locale", but the control panels offer such an option. I tried with the bug-1301640-FF, but changing to English/US or /AU or /GB or German/DE made no difference in the date/time display. What am I missing?

About the Indians. I once met a telemetry guy, Georg Fritzsche, in a meeting and he told us about http://bsmedberg.github.io/telemetry-dashboard/new-pipeline/active-weekly.html and its surprising results. One was the Indians in India use, much to my surprise, an en-US version and not an en-GB version. And there was an Indian chap in the room who confirmed that. The Hindi version is practically not used.

I don't know how they deal with date/time. I'd imagine that they also use Windows (en-US, like myself) and then fix the date/time display individually.

So according to your solution: What should an Indian install (or myself, who's also using an en-US FF) and how should they get the date/time display they want?

I'm also surprised about the discussion in bug 1301640. First there were concerns about not honouring user defined formats, and then the bug was landed and caused exactly this, which is the subject of this bug.

Comment 6

[Jorg K (CEST = GMT+2)]

I also tried to change intl.locale.matchOS but whatever I did, the bug-1301640-FF showed unchanged:
December 25, 2016, 7:23:07 PM

Comment 7

[Jorg K (CEST = GMT+2)]

Sorry for yet another post here:

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #4)
("I want my app to ignore my app's locale!")
("I changed my browser's locale and and it still follows my OS locale!").

You seem to suggest that the app/browser has it's own (changeable) locale and follows it. Fine.
Where is that locale, and how do you change it?

If you think that the browser should not follow the OS, fine, just tell me where to change what the browser does.

Comment 8

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

(In reply to Jorg K (GMT+1) from comment #5)
> I grabbed a copy of FF with the change from bug 1301640 included, so I can
> experiment. Just a few questions.
> 
> What is browser locale?

The locale you choose from your preferences panel

> What about pref general.useragent.locale?

Exactly that's it :)

> I also tried to change intl.locale.matchOS but whatever I did, the bug-1301640-FF showed unchanged:
December 25, 2016, 7:23:07 PM

That's a bug. It should follow general.useragent.locale.



> > The browser locale follow's system locale, until manually changed.
> Please explain. I'm on Windows, so there is limited scope in changing the
> "locale", but the control panels offer such an option. I tried with the
> bug-1301640-FF, but changing to English/US or /AU or /GB or German/DE made
> no difference in the date/time display. What am I missing?

Control panel of what? OS or the web browser.

We are aiming to follow the locale selected for the web browser.

When you change the locale of your web browser your date/time should follow.

> One was the Indians in India use, much to
> my surprise, an en-US version and not an en-GB version. And there was an
> Indian chap in the room who confirmed that. The Hindi version is practically
> not used.
> I don't know how they deal with date/time. I'd imagine that they also use
> Windows (en-US, like myself) and then fix the date/time display individually.

That seems to be an UX bug. if Windows offers en-IN, that should be what they follow as it's exactly what you described - en language with IN region settings.

So, as much as I recognize the importance of any single market, I don't believe we should:

a) ignore the designed solutions to the problem
b) shape API around a single use-case

> So according to your solution: What should an Indian install

They should install en-IN web browser, or install en-US/en-GB and select en-IN locale in their browser.

> (or myself, who's also using an en-US FF) and how should they get the date/time display
> they want?

Same for you.

We should also respect any manually changed options that you placed - like hour12/24, date/time formats, decimal separators etc.

> I'm also surprised about the discussion in bug 1301640. First there were
> concerns about not honouring user defined formats, and then the bug was
> landed and caused exactly this, which is the subject of this bug.

Yes, we recognized it and backed out the patch.

We're trying to get the Firefox UI to follow public Intl API. It creates tension wherever the API does not support something and we need it.
In those cases we are trying to push the standardization body to design a solution, but if that takes more time (which it will in that case), we'll probably design a solution for Firefox UI only (so, it won't be exposed to the web content).

In this case, additional challenge is that we are dealing with privacy/fingerprinting related issue which makes everything just a level harder :)

I understand your frustration, I apologies for it. It's hard to get everything right, but we're trying to.

I'll close this bug as a dupe of bug 1308329.

Thanks for reporting it! I appreciate the contribution.

Also, just as a reminder, Mozilla's etiquette states that bugs are not places where we argue about the solution, but for technical conversations about the implementation.

If you want to discuss the approach, we should do this in the newsgroup - either mozilla.dev.platform (Platform issues) or mozilla.tools.l10n (L10n/Intl issues). Thanks!

Comment 9

[Jorg K (CEST = GMT+2)]

I'm a bit surprised about the reference to the Mozilla etiquette and such when I'm just trying to understand what you tried to do in bug 1301640.

BTW, I'm a Thunderbird developer and member of the Thunderbird Council and well aware of BMO etiquette. Was bug 1301640 discussed on dev-platform? Did I miss something (not that I follow dev-platform closely).

Sadly I'm also the poor guy who had to fix the bustage you caused on Christmas Eve by landing bug 1301640 without any prior notice:
https://hg.mozilla.org/comm-central/rev/a6298203de72b408d580f604e9a336d2b70068bf
And I will have to back this out once the backout from bug 1301640 is merged to M-C.

So perhaps you'll have the kindness to reply to my questions.

From what I understand so far is that there are two preferences:
general.useragent.locale and intl.locale.matchOS.

The former is apparently the locale of the browser and the latter tells FF whether to look at the OS locale at start-up.

So let's take my FF 50 (release):
general.useragent.locale is en-US
intl.locale.matchOS is true.
Windows reports: System Locale: en-au;English (Australia)
After restarting, general.useragent.locale is still en-US, so maybe intl.locale.matchOS is ignored.
In any case: The date display comes from the OS definition, not the en-US locale.

Now the FF with the patch from bug 1301640. What I understood from the discussion is that that version was no longer picking up the OS defined values, but instead the ICU / CLDR values.
So I set general.useragent.locale to de-DE or en-AU or en-GB and still get |December 25, 2016, 8:50:16 PM|
The commit message on the backout reads: Backed out for causing bug 1325751.

So was it backed out because the OS formats were no longer honoured (which was already a known fact) or was it backed out since it didn't achieve what it set out to do, that is use the formats according to the set browser locale in general.useragent.locale?

I'm fine with what you said in comment #8: "... or install en-US/en-GB and select en-IN locale in their browser", but that didn't work in this particular version.

Comment 10

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

> I'm a bit surprised about the reference to the Mozilla etiquette and such when I'm just trying to understand what you tried to do in bug 1301640.

That was more meant in context of holding a conversation on how we should approach OS vs ICU/CLDR intl data.

> So was it backed out because the OS formats were no longer honoured (which was already a known fact) or was it backed out since it didn't achieve what it set out to do, that is use the formats according to the set browser locale in general.useragent.locale?

My take is that it was backed out because we got feedback from the community that not respecting OS intl preferences has a significant impact on the UX. Something that web apps don't do (they cannot follow OS preferences since Intl API doesn't expose them) and I guess we assumed that it'll be ok to first transition toward ICU based solution and then add host env. preferences.