What use cases is this intended to support?

[gibson042]

A relevant observation about how users don't really have locale preference rankings, at least not in many cases: https://twitter.com/hsivonen/status/1301456494534234117

The user’s preference order of languages is the big fallacy of language negotiation in software. In reality, the top-preferred languages don’t have a fixed order but form an accept set and the user wants the least translated version within the accept set.

The ECMA-402 algorithms are not necessarily well-adapted to support that.

[longlho]

Maybe I've misunderstood, but would this be equivalent to a weighted list of locales with everything having the same weight?

[lifaon74]

Well actually, I would love to have this functionality.

Here is a practical example:

• you have many translations for your application (lets say 'fr.json', 'en.json', 'de.json')
• your user is French Canadian. Its locales will be ['fr-CA', 'en'] (navigator.languages)

Calling Intl.LocaleMatcher.match(navigator.languages, ["fr", "en", "de"], "en"); would help to resolve the best fitting translation file for your app.

=> 'fr.json' in the case of our French Canadian

[longlho]

yes that's the primary use case we're proposing to support.

[tkrotoff]

Intl.LocaleMatcher.match(navigator.languages, ["fr", "en", "de"], "en");

yes that's the primary use case we're proposing to support.

@longlho

Then why Intl.LocaleMatcher.match requestedLocales doesn't take (also) a string?

Do we have to manually parse HTTP header Accept-Language or navigator.languages string? (e.g. 'fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5')
What about * which is a valid Accept-Language value?

[longlho]

Yeah you should parse it