Normative: add intl-displaynames-v2 #622

FrankYFTang · 2021-11-04T21:26:35Z

Based on https://tc39.es/intl-displaynames-v2/

pending on TC39 2021-Dec decision

Based on https://tc39.es/intl-displaynames-v2/ pending on TC39 2021-Dec decision

ryzokuken

LGTM overall, please check out my feedback inline.

spec/displaynames.html

ryzokuken · 2021-12-01T14:09:37Z

spec/displaynames.html

        <li>The display name style fields under display name type *"language"* should contain Records with keys corresponding to language codes matching the `unicode_language_id` production. The value of these fields must be string values.</li>
        <li>The display name style fields under display name type *"region"* should contain Records with keys corresponding to region codes. The value of these fields must be string values.</li>
        <li>The display name style fields under display name type *"script"* should contain Records with keys corresponding to script codes. The value of these fields must be string values.</li>
        <li>The display name style fields under display name type *"currency"* should contain Records with keys corresponding to currency codes. The value of these fields must be string values.</li>
+        <li>The display name styles fields under display name type `"calendar"` should contain Records, with keys corresponding to a String value with the `type` given in Unicode Technical Standard 35 for the calendar used for formatting. The value of these fields must be string values.</li>


Suggested change

<li>The display name styles fields under display name type `"calendar"` should contain Records, with keys corresponding to a String value with the `type` given in Unicode Technical Standard 35 for the calendar used for formatting. The value of these fields must be string values.</li>

<li>The display name style fields under display name type `"calendar"` should contain Records with keys corresponding to a String value with the `type` given in Unicode Technical Standard 35 for the calendar used for formatting. The value of these fields must be string values.</li>

It seems like you say "string" twice here, so maybe that could be fixed?

The "styles fields" were referring to those fields inside typeFields "26. Let styleFields be typeFields.[[<style>]].". If you look at the spec text before, I wrote the same way. If we want to change it, I think we should make an editorial changes on ECMA402 on the preexisting one separated from here.

ryzokuken · 2021-12-01T14:13:20Z

spec/displaynames.html

        <li>The display name style fields under display name type *"language"* should contain Records with keys corresponding to language codes matching the `unicode_language_id` production. The value of these fields must be string values.</li>
        <li>The display name style fields under display name type *"region"* should contain Records with keys corresponding to region codes. The value of these fields must be string values.</li>
        <li>The display name style fields under display name type *"script"* should contain Records with keys corresponding to script codes. The value of these fields must be string values.</li>
        <li>The display name style fields under display name type *"currency"* should contain Records with keys corresponding to currency codes. The value of these fields must be string values.</li>
+        <li>The display name styles fields under display name type `"calendar"` should contain Records, with keys corresponding to a String value with the `type` given in Unicode Technical Standard 35 for the calendar used for formatting. The value of these fields must be string values.</li>
+        <li>The display name styles fields under display name type `"dateTimeField"` should contain Records, with keys corresponding to codes listed in <emu-xref href="#table-validcodefordatetimefield"></emu-xref>. The value of these fields must be string values.</li>


Suggested change

<li>The display name styles fields under display name type `"dateTimeField"` should contain Records, with keys corresponding to codes listed in <emu-xref href="#table-validcodefordatetimefield"></emu-xref>. The value of these fields must be string values.</li>

<li>The display name style fields under display name type `"dateTimeField"` should contain Records with keys corresponding to codes listed in <emu-xref href="#table-validcodefordatetimefield"></emu-xref>. The value of these fields must be string values.</li>

ryzokuken · 2021-12-01T14:54:06Z

One more thing: since this is a new addition, should this use the new structured argument syntax for new AOs? Otherwise it would increase the amount of editorial work.

spec/displaynames.html

Correct incorrect insertion point of proposed changes

FrankYFTang · 2021-12-01T20:30:39Z

One more thing: since this is a new addition, should this use the new structured argument syntax for new AOs? Otherwise it would increase the amount of editorial work.

you are talking about IsValidDateTimeFieldCode right? I will change it accordingly later today.

FrankYFTang · 2021-12-02T10:56:28Z

One more thing: since this is a new addition, should this use the new structured argument syntax for new AOs? Otherwise it would increase the amount of editorial work.

DONE

FrankYFTang · 2021-12-02T10:57:18Z

PTAL

spec/displaynames.html

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

FrankYFTang · 2021-12-30T23:40:57Z

@gibson042 @ryzokuken Is there any action I need to take for this PR?

ryzokuken

LGTM overall, just that old comment about rewording one sentence, would be nice if you addressed it.

spec/displaynames.html

FrankYFTang · 2022-01-06T17:27:03Z

PTAL

ryzokuken · 2022-01-07T19:01:05Z

Looks great, @gibson042 would you like to review this before we hit merge?

gibson042

No firm objection to merging as-is, but I do have a question about what seems like a mistake.

gibson042 · 2022-01-07T19:10:41Z

spec/displaynames.html

@@ -68,8 +151,13 @@ <h1>Intl.DisplayNames ( _locales_, _options_ )</h1>
        1. Let _dataLocaleData_ be _localeData_.[[&lt;_dataLocale_&gt;]].
        1. Let _types_ be _dataLocaleData_.[[types]].
        1. Assert: _types_ is a Record (see <emu-xref href="#sec-Intl.DisplayNames-internal-slots"></emu-xref>).
+        1. Let _languageDisplay_ be ? GetOption(_options_, *"languageDisplay"*, *"string"*, &laquo; *"dialect"*, *"standard"* &raquo;, *"dialect"*).


Is it intentional to read languageDisplay even if type is not "language"? The consequences are observable to ECMAScript code, e.g.

new Intl.DisplayNames(undefined, { type: "currency", get languageDisplay(){ throw new Error("[[Get]] languageDisplay") } })

Please see tc39/proposal-intl-displaynames-v2#34

4. Intl.DisplayNames ( locales, options ) Normal convention should still be to always validate all options, even when unused. That means the GetOption(options, "languageDisplay", ...) step should happen before If type is "language", then. (But don't move assigning displayNames.[[LanguageDisplay]] outside of the if-step.) For example compare to SetNumberFormatUnitOptions().

ryzokuken · 2022-01-12T11:20:54Z

I think all outstanding comments have been addressed and this PR has the editorial signoffs needed? Merging.

Proposal reached stage 4, was integrated in Ecma402 and now returns a 404: tc39/proposals@f4378e1 tc39/ecma402#622

* Drop Intl.displayNames v2 proposal, merged in Ecma402 Proposal reached stage 4, was integrated in Ecma402 and now returns a 404: tc39/proposals@f4378e1 tc39/ecma402#622 * Drop Intl.Segmenter proposal, merged in Ecma402 Proposal moved to stage 4, and was merged in Ecma402: tc39/proposals@24bdab7 tc39/ecma402#553

Stage4 PR for intl-displaynames-v2

b1a2f9d

Based on https://tc39.es/intl-displaynames-v2/ pending on TC39 2021-Dec decision

FrankYFTang requested review from ryzokuken and gibson042 November 4, 2021 21:26

FrankYFTang mentioned this pull request Nov 4, 2021

Need to create the Stage 4 PR tc39/proposal-intl-displaynames-v2#39

Closed

ryzokuken requested changes Dec 1, 2021

View reviewed changes

ljharb reviewed Dec 1, 2021

View reviewed changes

spec/displaynames.html Outdated Show resolved Hide resolved

ljharb reviewed Dec 1, 2021

View reviewed changes

spec/displaynames.html Outdated Show resolved Hide resolved

FrankYFTang added 3 commits December 1, 2021 12:08

Move two lines up

17cb463

Correct incorrect insertion point of proposed changes

Change ` to *

476edaa

Change "` to "*

1cfcd76

Use the new structured argument syntax for new AOs

58e7d8d

FrankYFTang requested review from ljharb and ryzokuken December 2, 2021 10:57

jridgewell mentioned this pull request Dec 14, 2021

Dec 2021 babel/proposals#78

Open

gibson042 approved these changes Dec 14, 2021

View reviewed changes

spec/displaynames.html Outdated Show resolved Hide resolved

spec/displaynames.html Outdated Show resolved Hide resolved

spec/displaynames.html Outdated Show resolved Hide resolved

spec/displaynames.html Outdated Show resolved Hide resolved

FrankYFTang and others added 4 commits December 14, 2021 16:14

Update spec/displaynames.html

67530a6

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

Update spec/displaynames.html

a0ed095

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

Update spec/displaynames.html

6a1ce05

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

Update spec/displaynames.html

5c80843

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

FrankYFTang requested a review from gibson042 December 30, 2021 23:40

ryzokuken approved these changes Jan 6, 2022

View reviewed changes

spec/displaynames.html Show resolved Hide resolved

ryzokuken added the normative label Jan 6, 2022

ryzokuken assigned FrankYFTang Jan 6, 2022

ryzokuken changed the title ~~Stage4 PR for intl-displaynames-v2~~ Normative: add intl-displaynames-v2 Jan 6, 2022

fix singlar for styles

4610b5c

Remove

8e30b71

gibson042 approved these changes Jan 7, 2022

View reviewed changes

ryzokuken merged commit 5b84c6f into tc39:master Jan 12, 2022

tidoust added a commit to w3c/browser-specs that referenced this pull request Jan 25, 2022

Drop Intl.displayNames v2 proposal, merged in Ecma402

8e56024

Proposal reached stage 4, was integrated in Ecma402 and now returns a 404: tc39/proposals@f4378e1 tc39/ecma402#622

FrankYFTang deleted the DisplayNamesStage4PR branch July 25, 2023 05:19

ben-allen mentioned this pull request Jun 1, 2024

Extensive updates needed for Intl.DisplayNames documentation tc39/ecma402-mdn#25

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Normative: add intl-displaynames-v2 #622

Normative: add intl-displaynames-v2 #622

FrankYFTang commented Nov 4, 2021

ryzokuken left a comment

ryzokuken Dec 1, 2021

ryzokuken Dec 1, 2021

FrankYFTang Dec 1, 2021

ryzokuken Dec 1, 2021

ryzokuken commented Dec 1, 2021

FrankYFTang commented Dec 1, 2021

FrankYFTang commented Dec 2, 2021

FrankYFTang commented Dec 2, 2021

FrankYFTang commented Dec 30, 2021

ryzokuken left a comment

FrankYFTang commented Jan 6, 2022

ryzokuken commented Jan 7, 2022

gibson042 left a comment

gibson042 Jan 7, 2022

FrankYFTang Jan 10, 2022

FrankYFTang Jan 10, 2022

ryzokuken commented Jan 12, 2022

	<li>The display name styles fields under display name type `"calendar"` should contain Records, with keys corresponding to a String value with the `type` given in Unicode Technical Standard 35 for the calendar used for formatting. The value of these fields must be string values.</li>
	<li>The display name style fields under display name type `"calendar"` should contain Records with keys corresponding to a String value with the `type` given in Unicode Technical Standard 35 for the calendar used for formatting. The value of these fields must be string values.</li>

Normative: add intl-displaynames-v2 #622

Normative: add intl-displaynames-v2 #622

Conversation

FrankYFTang commented Nov 4, 2021

ryzokuken left a comment

Choose a reason for hiding this comment

ryzokuken Dec 1, 2021

Choose a reason for hiding this comment

ryzokuken Dec 1, 2021

Choose a reason for hiding this comment

FrankYFTang Dec 1, 2021

Choose a reason for hiding this comment

ryzokuken Dec 1, 2021

Choose a reason for hiding this comment

ryzokuken commented Dec 1, 2021

FrankYFTang commented Dec 1, 2021

FrankYFTang commented Dec 2, 2021

FrankYFTang commented Dec 2, 2021

FrankYFTang commented Dec 30, 2021

ryzokuken left a comment

Choose a reason for hiding this comment

FrankYFTang commented Jan 6, 2022

ryzokuken commented Jan 7, 2022

gibson042 left a comment

Choose a reason for hiding this comment

gibson042 Jan 7, 2022

Choose a reason for hiding this comment

FrankYFTang Jan 10, 2022

Choose a reason for hiding this comment

FrankYFTang Jan 10, 2022

Choose a reason for hiding this comment

ryzokuken commented Jan 12, 2022