Editorial: Modernise spec to use structured headers and correct number representations #822
Conversation
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
anba
commented
Aug 9, 2023
|
Not a review, but I just wanted to say a heartfelt thank you for doing this ❤️ |
anba
commented
Aug 9, 2023
anba
commented
Aug 9, 2023
anba
commented
Aug 9, 2023
anba
commented
Aug 9, 2023
ryzokuken
approved these changes
Aug 10, 2023
This was referenced Aug 11, 2023
anba
added a commit
to anba/proposal-intl-duration-format
that referenced
this pull request
Aug 22, 2023
anba
added a commit
to anba/proposal-intl-duration-format
that referenced
this pull request
Aug 22, 2023
ben-allen
approved these changes
Sep 7, 2023
|
@gibson042 Any objections to merging this one? |
gibson042
approved these changes
Sep 15, 2023
|
@gibson042 Do you think this one is mergeable as stands? |
|
Yes, but there would be substantial followup churn. |
anba
added a commit
to anba/ecma402
that referenced
this pull request
Sep 25, 2023
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".
|
Fixed all review suggestions (except the suggestion to use Number values in internal slots). I've also updated
(Note: Updating ecmarkup also leads to using the new font.) |
anba
added a commit
to anba/ecma402
that referenced
this pull request
Sep 27, 2023
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".
Thanks, all fixed now. |
bakkot
reviewed
Sep 27, 2023
anba
added a commit
to anba/ecma402
that referenced
this pull request
Sep 28, 2023
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".
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".
|
Updated again to resolve merge conflicts with latest changes to the main branch. |
|
Thank you again so much for this! |
ben-allen
pushed a commit
to ben-allen/ecma402
that referenced
this pull request
Oct 12, 2023
…r representations (tc39#822) Sweeping changes across the entire spec to update ECMA-402 to use structured headers as used in ECMA-262 Also contains related refactoring, plus updates to represent numbers correctly/consistently
ryzokuken
pushed a commit
to ryzokuken/ecma402
that referenced
this pull request
Oct 12, 2023
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".
ben-allen
pushed a commit
to tc39/proposal-intl-duration-format
that referenced
this pull request
Oct 16, 2023
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.
No description provided.