Internationalization: Additional values in API
Mark Davis ☕
mark at macchiato.com
Tue Jun 26 16:02:41 PDT 2012
I tend to agree with your proposal.
Some caveats below.
*— Il meglio è l’inimico del bene —*
On Tue, Jun 26, 2012 at 3:22 PM, Norbert Lindenberg <
ecmascript at norbertlindenberg.com> wrote:
> The TC 39 meeting on 2012-05-21 decided to allow implementations to
> recognize property values for which the specification prescribes an Error
> > - 2. Conformance
> > - What about already defined properties? Can we add new,
> implementation specific values, like v8Identical for collator sensitivity?
> > - We should throw if we don't recognise the value. You may recognise
> additional property values.
> I'd like to propose a more restricted escape hatch, to be added to the
> existing allowances for additional objects, properties, and functions in
> the Conformance clause:
> In the following cases where the specification requires that a RangeError
> is thrown for unacceptable input values, implementations may define
> additional acceptable input values for which the RangeError is not thrown:
> - The options property localeMatcher in all constructors and
> supportedLocalesOf methods.
> - The options properties usage and sensitivity in the Collator constructor.
> - The options properties style, currencyDisplay, minimumIntegerDigits,
> minimumFractionDigits, maximumFractionDigits, minimumSignificantDigits, and
> maximumSignificantDigits in the NumberFormat constructor.
The ones that are integers it would seem odd to accept others.
> - The options property timeZone in the DateTimeFormat constructor,
> provided that the additional acceptable input values are case-insensitive
> matches of Zone or Link identifiers in the IANA time zone database  and
> are canonicalized to Zone identifiers in the casing used in the database
> for DateTimeFormat.resolvedOptions().timeZone, except that "Etc/GMT" shall
> be canonicalized to "UTC".
I agree with your reasoning below, but would I would rather use the CLDR
values in http://unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml,
since they are based on the TZDB but mroe stable. Either just names or
names + aliases.
> - The options properties listed in table 3 in the DateTimeFormat
> - The options property formatMatcher in the DateTimeFormat constructor.
> The above prevents additional values in the following cases:
> - Input values that lead to TypeError exceptions. These are usually not
> meaningful extension points.
> - Input values that are boolean. There just aren't additional meaningful
> boolean values.
> - Language tags that are not structurally valid. Structural validity is a
> quite minimal requirement, and BCP 47 itself is very extensible. Allowing
> additional values in the Internationalization API would only create
> - Currency codes that are not well-formed. Here as well, well-formedness
> is a quite minimal requirement, and ISO 4217 itself allows registration of
> any actual new currency codes. Allowing additional values in the
> Internationalization API would only create confusion.
> - Additional keys and values from Unicode Technical Standard 35, Unicode
> Locale Data Markup Language . UTS 35 defines several keys and values
> that we have agreed are not useful for the Internationalization API, so we
> should be able to screen new ones before they're added.
I'm a bit hesitant about the screening, since it may take a while (looking
at history) between updates, unless there is a lighter-weight mechanism.
> - NaN and +/- Infinity in DateTimeFormat.prototype.format. These just
> aren't meaningful time values.
> The most unusual part of the proposed addition to the Conformance clause
> is the mini-specification for additional time zone identifiers. In the
> discussions on DateTimeFormat, we deferred defining support for a larger
> set of time zones because not all implementations are ready to support
> them. If we allow implementations to accept additional values, however,
> it's a pretty safe guess that several implementations will extend the set
> of supported time zones quickly, because applications need it, and it's
> also a pretty safe guess that they'll build their support around the IANA
> time zone IDs , and that the values would not be prefixed. There may
> however be inconsistencies around case significance and around
> canonicalization of the names in DateTimeFormat.prototype.resolvedOptions.
> In this situation, I think it would be better to standardize now which
> values may get accepted optionally and how they're processed.
>  https://mail.mozilla.org/pipermail/es-discuss/2012-May/022836.html
>  http://www.iana.org/time-zones/
>  http://unicode.org/reports/tr35/
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss