forked from tc39/ecma402
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Editorial: Add GetLocale{Language,Script,Region,Variants} operations
Add new `GetLocale{Language,Script,Region,Variants}` operations to retrieve the corresponding subtags from a locale tag. These new operations are used in `ApplyOptionsToTag`, `IsStructurallyValidLanguageTag`, and the `Intl.Locale.prototype` accessor functions. GetLocaleLanguage: Returns the longest prefix matching `unicode_language_subtag`. The previous definitions could be misinterpreted to match variant subtags whose length is larger than the language subtag. For example in "en-basiceng"` the longest substring matching `unicode_language_subtag` is "basiceng". GetLocaleScript: The previous definition from `Intl.Locale.prototype.script` is reused. GetLocaleRegion: Instead of using the previous definition from `Intl.Locale.prototype.region`, it was rewritten to match definition from `GetLocaleScript` a bit more closely. To not confuse language and region subtags, the leading language subtag is first removed before searching for `unicode_region_subtag`. GetLocaleVariants: Uses the suggestion from code review in tc39#822. The leading "-" character is removed for consistency with the other three new operations. `get Intl.prototype.{language,script,region}` are now all simply calling the new abstract operations to retrieve the subtags. `ApplyOptionsToTag` uses the new operations to retrieve the subtags from the original language tag when the corresponding option is absent. The updated `languageId` is now manually constructed through string concatenation instead of using subtag matching. `IsStructurallyValidLanguageTag` now calls `GetLocaleVariants` to retrieve the variant subtags. The variable `lang` was renamed to `languageId` for consistency with the rest of the spec and because `lang` can be more easily misinterpreted to stand for "language". `CanonicalizeUnicodeLocaleId` was changed to fix the incorrect redeclaration warning for `extension` from ecmarkup: - Instead of using yet another way to retrieve the Unicode extension sequence, simply use the existing terms "Unicode locale extension sequence". (The existing term already makes sure that substrings in private-use subtags are ignored, so we don't have to worry about `pu_extensions`. - "Unicode locale extension sequences" include the leading "-" character, so `newExtension` actually needs to be initialised with "-u".
- Loading branch information
Showing
2 changed files
with
95 additions
and
43 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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