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

Normative: Add Locale.prototype.getVariants #960

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

gibson042
Copy link
Contributor

Fixes #900

I was reminded of this by tc39/test262#4394.

1. Perform ? RequireInternalSlot(_loc_, [[InitializedLocale]]).
1. Let _variantsString_ be GetLocaleVariants(_loc_.[[Locale]]).
1. Let _variantsList_ be StringSplitToList(_variantsString_, *"-"*).
1. Return CreateArrayFromList(_variantsList_).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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.

@FrankYFTang
Copy link
Contributor

If we do this, then how about setting variants in option bag them?

@gibson042
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Priority Issues
Development

Successfully merging this pull request may close these issues.

Why is there no Intl.Locale.prototype.variants?
2 participants