Array.prototype.toLocaleString needs to be respecified to
- pass locales and options arguments on to the array's elements, and
- to use a localized list separator.
See
https://mail.mozilla.org/pipermail/es-discuss/2013-December/thread.html#35248
Starting in the ES6 spec. Rev26, Array.prototype.toLocaleString says that if Ecma-402 is implemented, the definition from 402 must be used. so we need to provide one.
Also, as pointed out by https://mail.mozilla.org/pipermail/es-discuss/2013-December/035252.html
The 402 version of Array.prototype.toLocaleString should validate the optional parameters before calling toLocaleString on any of the array elements.
I've copied the existing specification text from Ecma-262 6ed. Rev 26 to Ecma-402 2ed. Rev 2
Next step is to update according to the notes in this thread.
(In reply to Norbert from comment #0)
> Array.prototype.toLocaleString needs to be respecified to
> - pass locales and options arguments on to the array's elements, and
I understand this to mean that each element has `toLocaleString(locales, options)` called (after validation). However: I don't see a definition for `String.prototype.toLocaleString`, which means it would call `O.p.toLocaleString` which does nothing with `locales` (or any argument).
Hopefully I've just missed something obvious.
(In reply to Rick Waldron from comment #4)
> (In reply to Norbert from comment #0)
> > Array.prototype.toLocaleString needs to be respecified to
> > - pass locales and options arguments on to the array's elements, and
>
> I understand this to mean that each element has `toLocaleString(locales,
> options)` called (after validation). However: I don't see a definition for
> `String.prototype.toLocaleString`, which means it would call
> `O.p.toLocaleString` which does nothing with `locales` (or any argument).
>
> Hopefully I've just missed something obvious.
that's ok. Presumably, there isn't anything locale specific that is appropriate to do for generic string value. So, O.p.toString will just delegate toLocaleString back to toString, producing the original string value.
(In reply to Allen Wirfs-Brock from comment #5)
> (In reply to Rick Waldron from comment #4)
> > (In reply to Norbert from comment #0)
> > > Array.prototype.toLocaleString needs to be respecified to
> > > - pass locales and options arguments on to the array's elements, and
> >
> > I understand this to mean that each element has `toLocaleString(locales,
> > options)` called (after validation). However: I don't see a definition for
> > `String.prototype.toLocaleString`, which means it would call
> > `O.p.toLocaleString` which does nothing with `locales` (or any argument).
> >
> > Hopefully I've just missed something obvious.
>
> that's ok. Presumably, there isn't anything locale specific that is
> appropriate to do for generic string value. So, O.p.toString will just
> delegate toLocaleString back to toString, producing the original string
> value.
Ok, that makes perfect sense.
Many objects will not do anything locale specific, so that toLocaleString returns the same string as toString. That's OK.
One open issue is whether toLocaleString on Array and Object should check the validity of the locales argument in the same way as the implementations on Date and Number, so that, for example, [].toLocaleString("i") throws an exception. It might be odd if the method let this invalid argument pass for an empty array, or for an array holding only locale-unaware objects, but then started throwing after a Date or Number object is added.