feat(@formatjs/intl-locale): support variants per latest spec#5904
Closed
Conversation
Member
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has required the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
graphite-app Bot
pushed a commit
that referenced
this pull request
Jan 15, 2026
### TL;DR Added the `variants` property to `Intl.Locale` and improved documentation for `CanonicalizeLocaleList`. ### What changed? - Added the `variants` getter to the `Intl.Locale` class that returns variant subtags joined with hyphens in alphabetical order - Added detection for the `variants` property in the `shouldPolyfill` function - Added comprehensive tests for the new `variants` property with various locale scenarios - Enhanced documentation in `intl-getcanonicallocales` with ECMA-402 spec references for better clarity ### How to test? - Run the new test cases that verify the `variants` property works correctly: - Returns `undefined` for locales without variants - Returns the variant string for locales with a single variant - Returns hyphen-joined variants in alphabetical order for locales with multiple variants - Handles various locale formats with scripts, extensions, and numeric variants ### Why make this change? This change implements the `variants` property that was added to ECMA-402 via PR #960 to align with other subtag accessors. The property provides access to the variant subtags of a locale, which was previously missing from the implementation. This brings the polyfill in line with the latest ECMA-402 specification. References: - https://tc39.es/ecma402/#sec-Intl.Locale.prototype.variants - tc39/ecma402#960 - tc39/ecma402#900
Merge activity
|
5e6525a to
7a28be5
Compare
This was referenced Jan 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

TL;DR
Added the
variantsproperty toIntl.Localeand improved documentation forCanonicalizeLocaleList.What changed?
variantsgetter to theIntl.Localeclass that returns variant subtags joined with hyphens in alphabetical ordervariantsproperty in theshouldPolyfillfunctionvariantsproperty with various locale scenariosintl-getcanonicallocaleswith ECMA-402 spec references for better clarityHow to test?
variantsproperty works correctly:undefinedfor locales without variantsWhy make this change?
This change implements the
variantsproperty that was added to ECMA-402 via PR #960 to align with other subtag accessors. The property provides access to the variant subtags of a locale, which was previously missing from the implementation. This brings the polyfill in line with the latest ECMA-402 specification.References:
Intl.Locale.prototype.variants? tc39/ecma402#900