Rev10 Ecma-402 Draft now available

[Rick Waldron]

PDFs and .doc file available at: http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts

- Technical Changes

  - https://bugs.ecmascript.org/show_bug.cgi?id=3804 Bug 3804 - Implement NewTarget and subclassing semantics

  - https://bugs.ecmascript.org/show_bug.cgi?id=3803 Bug 3803 - Update "new expressions" to Construct(...)

- Editorial Changes

  - Updates to spec naming: "ECMAScript 2015 Internationalization API Specification"

Please file bugs here: https://bugs.ecmascript.org/enter_bug.cgi?product=Internationalization%20-%20ECMA-402

New proposal repo: https://github.com/tc39/ecma402

[Steven R. Loomis]

Rick,
Comments here - will sort out into bugs:

Comments on draft Rev 10, 2015-02-17 - page numbers as printed

. p2: Why Unicode 5.0 to 5.1 specifically? reason may just
be conformance - https://bugs.ecmascript.org/show_bug.cgi?id=3789

. p14 - "TODO define [[[[CreateAction]]]]" (on Collator) -
should there be a new bug for this?

. p15 - similar, "TODO pending subclass specification" - bug?

. p20 - SupportedLocales throw exception - what needs to
happen here?

. p20 - "cu" vs "nu" - Should it be said here that the value
of "cu" has no effect on Intl.NumberFormat?

. p24 - Numbering systems in CLDR but not listed here: brah
cakm cham java kali lana lanatham lepc mtei mymrshan nkoo
olck osma saur shrd sora sund takr talu vaii -
http://www.unicode.org/repos/cldr/trunk/common/bcp47/number.xml
- file a bug to update the chart? - actually,
https://bugs.ecmascript.org/show_bug.cgi?id=227 - I added a
comment

. p31 - why does the 'gregory' comment have a 'TODO remove'?
Perhaps it is redundant, or those were removed from ES6?

. p32 - "Table 3" deleted - still leaves a hanging "in"?

. p35 - Array.prototype.toLocaleString - I didn't realize
that this was a List pattern before. Should it reference
anything informative such as
http://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns
? Otherwise it is not clear what it refers to. I'm still
not entirely clear.. however
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toLocaleString
seems to think it is simply a single string (such as a comma
or
equivalent)
and link to
http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.4.3
and
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.tolocalestring
which don't specify any further. Furthermore, the
definition seems to specify a single "separator" so it is
not sufficient for uses such as "A, B, and C" or
equivalent. I guess this function has "options", so it can
be extended. I still don't think the specification in draft
10 gives enough information for implementations.

> --
> You received this message because you are subscribed to the Google
> Groups "JavaScript Globalization" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to javascript-globali...@googlegroups.com
> <mailto:javascript-globali...@googlegroups.com>.
> To post to this group, send email to
> javascript-g...@googlegroups.com
> <mailto:javascript-g...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/javascript-globalization/295e6137-be02-4675-8d52-3066a21a0cc9%40googlegroups.com
> <https://groups.google.com/d/msgid/javascript-globalization/295e6137-be02-4675-8d52-3066a21a0cc9%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
IBMer but all opinions are mine. // GPG: 9731166CD8E23A83BEE7C6D3ACA5DBE1FD8FABF1
https://www.ohloh.net/accounts/srl295 // https://ssl.icu-project.org/trac/wiki/Srl

[Rick Waldron]

Inline...

On Sat Feb 21 2015 at 2:43:51 AM Steven R. Loomis <s...@icu-project.org> wrote:

Rick,
 Comments here - will sort out into bugs:

Comments on draft Rev 10, 2015-02-17 - page numbers as printed

. p2: Why Unicode 5.0 to 5.1 specifically? reason may just
be conformance - https://bugs.ecmascript.org/show_bug.cgi?id=3789

Because ECMA-262, 6th Edition cites the Unicode Standard, Version 5.1.0 (or later). Since the two specifications are to be published as a coordinated set, they must cite the same normative references. 

https://bugs.ecmascript.org/show_bug.cgi?id=1260

 

. p14 - "TODO define [[[[CreateAction]]]]" (on Collator) -
should there be a new bug for this?

. p15 - similar, "TODO pending subclass specification" - bug?

. p20 - SupportedLocales throw exception - what needs to
happen here?

Nothing to be done for these, the comments are junk/out-dated/irrelevant/notes-to-self. (All Removed)

 

. p20 - "cu" vs "nu" - Should it be said here that the value
of "cu" has no effect on Intl.NumberFormat?

There's no reason not to? Please file a bug containing the exact text, as well as location on p20 and I will add it. 

 

. p24 - Numbering systems in CLDR but not listed here:  brah
cakm cham java kali lana lanatham lepc mtei mymrshan nkoo
olck osma saur shrd sora sund takr talu vaii -
http://www.unicode.org/repos/cldr/trunk/common/bcp47/number.xml
- file a bug to update the chart?  - actually,
https://bugs.ecmascript.org/show_bug.cgi?id=227 - I added a
comment

Does CLDR 26.0.1 have a table with the relevant data necessary for Table 2—specifically, I need the Digits ranges for the missing entries. 

 

. p31 - why does the 'gregory' comment have a 'TODO remove'?
Perhaps it is redundant, or those were removed from ES6?

The comment is no longer relevant https://bugs.ecmascript.org/show_bug.cgi?id=1260#c6 (Removed)

 

. p32 - "Table 3" deleted - still leaves a hanging "in"?

Microsoft Word is funny. I bet that "Deleted: Table 3" comment appeared as a result of something like...

- Select the text "Table 3"

- Place cursor into the "Search" field

- command-v—whoops, Word just pasted the text "Table 3" next to the text that was just selected!

- Delete the pasted text by some means other than command-z

This would result in that comment—which is obviously wrong and makes no sense. (Removed)

 

. p35 - Array.prototype.toLocaleString - I didn't realize
that this was a List pattern before. Should it reference
anything informative such as
http://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns
? Otherwise it is not clear what it refers to.   I'm still
not entirely clear.. however
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toLocaleString
seems to think it is simply a single string (such as a comma
                                                  or
                                                  equivalent)
and link to
http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.4.3
and
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.tolocalestring
which don't specify any further.  Furthermore, the
definition seems to specify a single "separator" so it is
not sufficient for uses such as "A, B, and C" or
equivalent. I guess this function has "options", so it can
be extended. I still don't think the specification in draft
10 gives enough information for implementations.

The operation does nothing more than call each individual element's toLocaleString method (13.2.1 Number.prototype.toLocaleString, 13.3.1 Date.prototype.toLocaleString or up the prototype chain to Object.prototype.toLocaleString, eg. strings). It's not a formatting or translating method and won't become one. Despite being implementation-defined, the separator will likely always be a comma, because that's what Array.prototype.toString does. All but two built-ins will delegate to Object.prototype.toLocaleString, which itself only calls the internal toString method of the target object, so the operations must align. There is a non-normative note that explains this: 

"The elements of the array are converted to Strings using their toLocaleString methods, and these Strings are then concatenated, separated by occurrences of a separator String that has been derived in an implementation-defined locale-specific way. The result of calling this function is intended to be analogous to the result of toString, except that the result of this function is intended to be locale-specific."

The optional arguments `locales` and `options` are solely used to pass through to each Array element's own toLocaleString method (if one exists). These can't be co-opted to change the behaviour of Array.prototype.toLocaleString, as they ultimately get passed through to internal-only abstract operations that expect them to be a certain shape.

The specification in draft 10 is very much implementable, as it's semantically identical to the existing ECMA-262, 5.1 specifications—the differences are solely in spec language and mechanics. 

List format capabilities should be specified as a new Intl.* API, in the 3rd edition. 

Rick