tc39 / proposal-intl-localematcher Goto Github PK

I suggest we add this functionality as a function in Intl instead of adding a new LocaleMatcher object.

Instead of

Intl.LocaleMatcher.match(["fr-XX", "en"], ["fr", "en"], "en"); // 'fr'

How about

Intl.matchLocale(["fr-XX", "en"], ["fr", "en"], "en"); // 'fr'

I should have mentioned that proposal repos should be based on the following template:

https://github.com/tc39/template-for-proposals

You can add this retroactively by merging the main branch from that repo into the main branch of this one.

This proposal was approved for Stage 1 on 2021-01-28. It should now be moved to the tc39 org. Please first transfer the repo to tc39-transfer, and then open an admin/business request for a chair to move it to tc39.

It is occasionally useful to be able to test if multiple locales are good candidates according a user's preferences. For example:

• Configuring spellcheckers for multiple languages.
• Display a locale <select> with the user's preferences hoisted to the top.

I will say it's totally possible to do this with just this API, it's just slightly involved:

let requestedLocales = ["fa-FR", "fr-FR"]
let availableLocales = ["en-US", "fr-FR", "fa-IR", "zh-Hans-CN"]
let defaultLocale = "en-US"
let options = { algorithm: "best fit" }
let fakeDefaultLocale = "en-x-ignore";

let matchedLocales = []

requestedLocales.forEach((requestedLocale) => {
  let match = Intl.LocaleMatcher.match(
    [requestedLocale], 
    availableLocales, 
    fakeDefaultLocale,
    options
  )
  if (match !== fakeDefaultLocale) {
    matchedLocales.push(match)
  }
})

if (matchedLocales.length === 0) {
  matchedLocales.push(defaultLocale)
}

// matchedLocales == ["fa-IR", "fr-FR"]

However, it seems like an easy thing to just bake into this API to make it more useful:

let matchedLocales = Intl.LocaleMatcher.matchMany(
  requestedLocales, 
  availableLocales, 
  defaultLocale,
  options
)
// matchedLocales == ["fa-IR", "fr-FR"]

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.

An application can also provide different "tones" of the same locales (e.g casual, formal), utilizing -x- private tag. Given a set of locales with extensions and what the user preference might be, find the best matching locales.

Ref: formatjs/formatjs#2642

cc @zbraniecki

In addition to returning an array of matched locales, I was wondering if we can actually return Intl.Locale[] instead. The benefit being that this solidify Intl.Locale as the data model representing Locale within ECMA402 and it also come already parsed with extensions builtin. Thoughts?