Getting the default locale

[sffc]

This is more of a question. Since the tag parameter is required per #15, is the following expression the correct way to get the default locale into an Intl.Locale object?

new Intl.Locale(navigator.language);

If so, I would like to add that to MDN, because I feel this is a common use case.

[aphillips]

Is that what we mean by default locale, though? I read #15 (and its antecedents) to mean the runtime locale of the host environment, e.g. my host machine is running in fr-FR but navigator.language is resolutely en-US. Shouldn't I get fr-FR and not en-US.

[sffc]

Which of those two locales is the one used by Intl.DateTimeFormat, for example? That's the one I mean by "default locale".

[zbraniecki]

It's pretty complicated actually.

In the web environment, the user sets one set of languages at the moment navigator.languages to express their intended fallback chain.

This is the list of language identifiers to be used when formatting dates, plural rules, numbers, currencies etc.

But, the host environment may set more specific data - for example POSIX allows you to specify LC_DATE separately from LC_MESSAGES and in theory that means that dates should be formatted differently from localization.

I resolved it in Gecko context by separating the "default locale" of the JS context depending of privileges.
chrome-privileged context (one used by Firefox UI itself) will have access to the OS preferences and will pick application locale, but the web-exposed context will follow navigator.languages to protect from fingerprinting (and other privacy issues).

So, when you ask for default locale, you may be asking for a locale that the JS context operates in (which, I'd argue, should be split into multiple different default locales following POSIX or at least Windows) or which languages the user requested the web content to be in (navigator.languages).

See the conversation in tc39/ecma402#109 and tc39/ecma402#68 for background.

[sffc]

OK, thanks for the reminders. My main reason for bringing this up was tc39/ecma402#390, where it would be useful to know which locale is default when constructing an Intl.DateTimeFormat with an undefined locale. But given tc39/ecma402#257 and your comments above, this is probably something better handled on the formatter level rather than globally.

[aphillips]

Is the concept of default in need of more work or specification?

I observe that the controls for accept language and language legends in browsers are usually buried and complex to use anyway. The usual (and probably desirable) behavior is to use the runtime device locale (LC_ALL in posix contexts) instead. Yay for that.

Navigator.language still seems to follow browser localization, which isn't that useful.

JS authors often want the page locale. I know that is what I usually want. I might look at the customer's browser as a hint for how to set that server side, but mostly I want my formatter to match the page I'm rendering. JS doesn't always run in the context of an html page, of course. I'm not fond of e.g. Java or ICU locale setDefault. But without some way to obtain and manage the context, a contextual default seems unlikely to work well. The ability to set and manage a contextual locale seems useful though.

(writing on an airplane on a phone so possibly incoherent)

[zbraniecki]

The usual (and probably desirable) behavior is to use the runtime device locale (LC_ALL in posix contexts) instead. Yay for that.
Navigator.language still seems to follow browser localization, which isn't that useful.

That's not as universal as you make it sound. People often use separate locale set for their browser UI from the locales the broadcast to the websites.

But a common scenario could be this: user has their browser in en-US and they set thier navigator.languages to ["fr-CA", "fr", "de", "en"]. It they end up on a website that doesn't have frlocale, but does havedelocale, the website will be inde`.

What should be JS default locale?

[aphillips]

I agree my statement sounded too universal.

In the example you give, it's the page locale that "wants" to be the default, I guess. My point is that this is set by the content, not the browser (and only indirectly by the customer, insofar as language negotiation made it de rather than something else).

[aphillips]

@sffc Should this be re-opened?

So this morning I was doing a code review of some Typescript code (implementing message format) and stumbled over a developer using new Intl.NumberFormat().resolvedOptions().locale to find out the default locale. This apparently is still the "canonical" way to find out what the "default locale" is in general. The problem is that this is a potentially expensive operation. The MDN documentation refers to "the default locale", but there is no way to find it out without building some formatter (or collator etc.) object. This seems undesirable.

Shouldn't there be a generic Locale interface to find out what the default locale is (for developers such as my team's who are writing "locale aware" functions)? It wouldn't prevent specific formatters or functions from using LC_xxx-style separate values. Or am I missing something?

[sffc]

Since Intl.Locale is merged, we should move the discussion to the mail ECMA-402 repo. I think the appropriate issue is: tc39/ecma402#68

[aphillips]

Sounds good. Thanks.