Allow for different default locale per category

[zbraniecki]

ECMA402 currently uses the notion of defaultLocale per JS context. https://tc39.github.io/ecma402/#sec-defaultlocale

This concept allows implementations to pick a default locale from places like - default locale used by the browser, or from the operating system - and use it for all intl formatters unless a different locale is provided to the function/constructor.

Unfortunately that does not apply well onto a scenario where the user separates the localization locale set from the internationalization locale set:

• Windows allows you to select UI locale set and Regional Preferences locale set
• Linux (POSIX) allows you to select LC_MESSAGES vs. LC_TIME vs. LC_COLLATE etc.

In both cases, we could provide better defaults for each Intl API if we could use different default locale per it. Clearly in a POSIX world, the default locale of Intl.Collator should come from LC_COLLATE, while Intl.DateTime should come from LC_TIME.

The only reason not to do that I can see is that it potentially increases the fingerprinting vector, but for multilingual users, who consciously chose to separate their UI locale from their intl locale, it seems like that's their expectation. (based on feedback I received from multilingual users of Firefox who are surprised to find that the browser ignores that)

[freaktechnik]

The only reason not to do that I can see is that it potentially increases the fingerprinting vector

As someone who would benefit from this change, this doesn't concern me that much, since my Accept-Language header already contains all locales that could be discovered with this and even some more. Of course the header is not coupled to my actual system settings.

[littledan]

What if we permit extension keys related to these concepts, and return them from navigator.locales?

[jungshik]

Related Chrome bugs are:

https://bugs.chromium.org/p/chromium/issues/detail?id=162173
and
https://bugs.chromium.org/p/chromium/issues/detail?id=33413 (and there are more).

[jungshik]

BTW, I'm not sure what @littledan meant :-).

[littledan]

@jungshik I was thinking of the Region Override key, but maybe I'm misunderstanding what that does.

[sffc]

Closing this issue per consensus:

https://github.com/tc39/ecma402/blob/master/meetings/notes-2020-02-27.md#allow-for-different-default-locale-per-category-257

[littledan]

Is the idea here, we'll follow up in navigator.locales, and maintain the prohibition of extension keys in the default locale, including the region override keys?

[sffc]

Is the idea here, we'll follow up in navigator.locales, and maintain the prohibition of extension keys in the default locale, including the region override keys?

My understanding is that once we get movement on navigator.locales, we will discuss whether or not the extension keys should be reflected in the default locale. I'd say that we should generally favor that approach. We have more discussion on that subject in other issues, though, like #68.