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

[lionel-rowe]

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.

I think that thread's recommendations are entirely consistent with what this proposal is trying to achieve (relevant bits below):

Lessons for app developers that I gathered by reading complaints about Finland’s (generally very good) COVID exposure notification app. Context: ... shipped only Finnish and Swedish as UI languages.

1. Always ship English UI strings in the first release even if the app is meant to be local to a country that doesn’t have English as an official language.
2. Always configure English as the fallback language. Users don’t configure secondary UI languages on the OS level. In this case, there are users who have set English as their phone UI language and complain about the app showing up in Finnish rather than Swedish.
3. For a locally-relevant app, it’s a good idea to provide an in-app language override so that users can pick a local language even if they have set the phone’s language to English (e.g. to avoid bad localizations in Google’s apps or other foreign apps).
   ...
   Epilogue: Is it reasonable to complain that you wanted Swedish even if your phone is set to English? I haven’t evaluated Google’s Swedish localizations, but I have my phone set to English and I’ve used in-app overrides to set Helsinki public transit and taxi apps to Finnish.
   ...
   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 logical "accept set" in this example would be [en, sv], of which sv probably isn't known to the software because the device doesn't surface that information/the user can't configure it. So the app sees the accept set as [en], and the available languages as [fi, sv], with the fallback being fi, thus it uses fi. In itself, that logic is reasonable, given that en isn't available and the region is Finland.

The way to make en available would be to translate the software into an additional language, which is a business decision. Meanwhile, the only software defect is that the app didn't allow the user to manually override the matched locale, nothing to do with the matching algorithm itself.

Treating Finnish as a substitute for Swedish wouldn't be enabled by this proposal, as the matching algorithms never consider the two to be equivalent. A better example would be using Norwegian Bokmål as a substitute for Nynorsk where Bokmål wasn't available.

EDIT: Maybe I'm wrong about this, assuming the formatjs polyfill implementation is correct:

import { match } from 'npm:@formatjs/intl-localematcher'
match(['sv'], ['fi'], 'en') // en (as expected)
match(['sv-FI'], ['fi-FI'], 'en') // fi-FI (!)
match(['fi-FI'], ['sv-FI'], 'en') // sv-FI (!)
match(['fi-FI'], ['it-FI'], 'en') // it-FI (!!)
match(['fi-FI'], ['hi-FI'], 'en') // en (!?)

AFAIK Italian isn't particularly more similar to Finnish than Hindi is, and neither are official/common languages in Finland, so I'm not sure why one falls back and the other doesn't.