#Intl LocaleMatcher ?

#Intl.LocaleMatcher

#动机

支持国际化（i18n）的网站通常通过 Accept-Language 请求头或 navigator.languages 获取用户偏好的语言环境列表。然后，它们会尝试根据自己支持（且已提供翻译）的语言环境集合来确定最佳可用语言环境。

此操作目前存在于 ECMA-402 中，但仅作为抽象操作提供。将此功能作为顶层 API 暴露出来，将提高语言环境协商的正确性和开发者的生产力，因为网站将能够可靠地处理不仅仅是匹配，还有别名、回退等情况。

#用例

1. 给定应用程序拥有翻译的一组语言环境以及用户请求的一组语言环境，找到最佳匹配的语言环境。
2. JS 运行时（和 polyfill）不要求保证支持所有语言环境。给定其支持的一组语言环境以及用户请求的语言环境，找到最佳匹配的语言环境。
3. 应用程序还可以利用 -x- 私有标签为相同的语言环境提供不同的“语气”（例如，随意、正式）。给定带有扩展的一组语言环境以及用户可能的偏好，找到最佳匹配的语言环境。

#状态

Stage 1

Ponyfill: https://formatjs.io/docs/polyfills/intl-localematcher

#引导人

• Long Ho (@longlho)

#API

interface Options {
    algorithm: 'lookup' | 'best fit'
}

Intl.LocaleMatcher.match(
    requestedLocales: string[],
    availableLocales: string[],
    defaultLocale: string,
    options?: Options
): string

#选项

1. lookup 将继续作为 ECMA-402 中现有的 LookupMatcher 实现。
2. best fit 将是实现相关的。

#示例

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

#相关先例

#@hapi/accept

这是 hapijs 头部解析的核心，带有质量偏好。但此法仅进行精确匹配的简单层级。例如：

Accept.language("en;q=0.7, fr-XX;q=0.8", ["fr", "en"]); // language === "en"

这并不准确。

#koa

类似地，Koa 的 request.acceptsLanguages 遵循类似的精确匹配算法。

#UTS35 LanguageMatching

这描述了一个更复杂的语言环境协商算法，比 hapi/koa 更准确。

#RFC4647 Section 3.4

这是 ECMA-402 中的 lookup 算法。

#cldrjs's lookup implementation

与 UTS35 LanguageMatching 类似。

#参考资料

• https://github.com/tc39/ecma402/issues/513
• https://github.com/tc39/ecma402/issues/46
• https://github.com/vercel/next.js/issues/18676