Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the API as a Intl.prototype function instead. #2

Open
FrankYFTang opened this issue Dec 3, 2020 · 1 comment
Open

Add the API as a Intl.prototype function instead. #2

FrankYFTang opened this issue Dec 3, 2020 · 1 comment

Comments

@FrankYFTang
Copy link

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'
@longlho
Copy link
Collaborator

longlho commented Dec 3, 2020

yeah I'm open to that as well. Although @sffc brought up a point where certain matching algorithm might require additional CLDR data so I can also see something like:

new Intl.LocaleMatcher({ algorithm: 'lookup' }) // This is the RFC4647 one that requires no addl data
(await new Intl.LocaleMatcher({ algorithm: 'unicode' })).match() // This is UTS35 LanguageMatching which needs maximize/minimize

Reference: tc39/ecma402#210

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants