When a String value is passed as the locales argument to the Intl constructors Collator, NumberFormat, and DateTimeFormat, or to their supportedLocalesOf methods, it is currently interpreted as a list of its individual characters:
- "" is interpreted as an empty array, which is acceptable (the constructors will generally fall back to the default locale). - "en-US" is interpreted as the array ["e", "n", "-", "U", "S"]. Individual characters cannot be valid language tags, so a RangeError is thrown. This happens because the CanonicalizeLocaleList abstract operation, following the path beaten by many built-ins in ES5, calls ToObject on the argument, and then finds length and indexed properties in the resulting String object. Using ToObject is an attempt to make (almost) any input usable by the rest of the operation, but from an application point of view it fails. Given that many applications will only have a single locale to pass in, I think it would be better to recognize strings specifically, and treat a String value by wrapping it into an array for further processing. This means inserting the following before the current step 3 of CanonicalizeLocaleList: (3) If locales is a String value, then (3a) Let locales be a new array created as if by the expression new Array(locales) where Array is the standard built-in constructor with that name and locales is the value of locales. The result would be that "" is rejected with a RangeError, but "en-US" is processed as ["en-US"]. Any objections? Thanks, Norbert _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
