-
Notifications
You must be signed in to change notification settings - Fork 106
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
Normative: Add Locale.prototype.getVariants #960
base: main
Are you sure you want to change the base?
Conversation
1. Perform ? RequireInternalSlot(_loc_, [[InitializedLocale]]). | ||
1. Let _variantsString_ be GetLocaleVariants(_loc_.[[Locale]]). | ||
1. Let _variantsList_ be StringSplitToList(_variantsString_, *"-"*). | ||
1. Return CreateArrayFromList(_variantsList_). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- @anba Should this also state the order need to be in alphabetical order ?
See the order discussion in
https://unicode.org/reports/tr35/#Canonical_Unicode_Locale_Identifiers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might benefit from a note, but nothing more—alphabetization is already required by use of CanonicalizeUnicodeLocaleId in the Intl.Locale constructor.
If we do this, then how about setting variants in option bag them? |
Good question, and I think the answer is "yes". This also interacts with the design question about representing variants as an array of strings or as a single dash-separated string, and I'm increasingly inclined towards the latter. |
Fixes #900
I was reminded of this by tc39/test262#4394.