Discuss
  • Internationalization: Issues with upgrading to UTS 35 version 21

Internationalization: Issues with upgrading to UTS 35 version 21

# Norbert Lindenberg (13 years ago)

The draft ECMAScript Internationalization API Specification [1] currently references Unicode Technical Standard 35, Unicode Locale Data Markup Language, version 2.0.1 or successor.

In order to get rid of the table of numbering systems in section 11.3.2, and to obtain up-to-date information about numbering systems from the BCP 47 Unicode Locale Extension registry, we'll have to upgrade to a later version of UTS 35, likely version 22.

UTS 35 version 21 [2] introduced some new features that create issues for the ECMAScript Internationalization API Specification:

  1. For collation, there's a new key "kr", reordering. This key is followed by a sequence of subtags, something that the ResolveLocale abstract operation (section 9.2.5) is currently not prepared to handle.

  2. For number formatting, there are new numbering systems "native", "traditio", and "finance". These are not mentioned in section 3 of UTS 35 (the official reference for Unicode Locale Extension information), but show up in section 5.10 as well as in the bcp47 data files [3]. They are convenient for requests, but seem inappropriate as identifiers, because they map to existing numbering system identifiers such as "latn" or "jpanfin" depending on the language tag they're attached to. I think the correct way of handling them in the Internationalization API would be to accept them as input, but canonicalize them to actual numbering system identifiers for format() and resolvedOptions().

It's a bit late to add any special handling for these new keys and values to edition 1 of the Internationalization API Specification. I propose that for edition 1 we declare them unsupported:

  1. Add "kr" to the list of "not allowed" values in the NOTE in section 10.2.3.

  2. For "native", "traditio", and "finance", add a sentence "The array that is the value of the 'nu' property of any locale property of [[localeData]] must not include the values 'native', 'traditio', or 'finance'." to the description of [[localeData]] in section 11.2.3.

We can then discuss better solutions for edition 2 of the spec.

Comments?

, Norbert

[1] globalization:specification_drafts [2] unicode.org/reports/tr35/tr35-25.html [3] unicode.org/cldr/trac/browser/trunk/common/bcp47/number.xml

# Gillam, Richard (13 years ago)

Norbert--

It's a bit late to add any special handling for these new keys and values to edition 1 of the Internationalization API Specification. I propose that for edition 1 we declare them unsupported:

  1. Add "kr" to the list of "not allowed" values in the NOTE in section 10.2.3.

  2. For "native", "traditio", and "finance", add a sentence "The array that is the value of the 'nu' property of any locale property of [[localeData]] must not include the values 'native', 'traditio', or 'finance'." to the description of [[localeData]] in section 11.2.3.

We can then discuss better solutions for edition 2 of the spec.

Comments?

Sounds like the right answer to me.

--Rich Gillam

# Phillips, Addison (13 years ago)

It's a bit late to add any special handling for these new keys and values to edition 1 of the Internationalization API Specification. I propose that for edition 1 we declare them unsupported:

  1. Add "kr" to the list of "not allowed" values in the NOTE in section 10.2.3.

  2. For "native", "traditio", and "finance", add a sentence "The array that is the value of the 'nu' property of any locale property of [[localeData]] must not include the values 'native', 'traditio', or 'finance'." to the description of [[localeData]] in section 11.2.3.

We can then discuss better solutions for edition 2 of the spec.

Comments?

Sounds like the right answer to me.

Ur... except that we use the 'kr' feature, Rich... :-)

I would prefer a standard that ignores unrecognized values rather than barfs on them ("now allowed"). I'll admit that I didn't go look at section 10.2.3 to see if that's what happens to disallowed values.

Addison

# Norbert Lindenberg (13 years ago)

"Not allowed" here means that implementations must ignore these keys and values if they occur in a Unicode locale extension sequence in a language tag.

Norbert

# Phillips, Addison (13 years ago)

Yes. That's what I'm objecting to.

BCP 47 allows for implementations to ignore what they don't understand/support. But it allows for implementations to support something that they do understand. I don't want to be forbidden to support something I intend to use. I don't mind not requiring others to support it (e.g. allowing them to ignore it).

Addison

# Norbert Lindenberg (13 years ago)

For the core BCP 47 (language, script, country), letting applications choose what to support makes sense and is how the Internationalization spec is written.

For the Unicode locale extension, however, we have to be more selective. The Unicode locale extension has

  • keys that should be fully under application control and hence not be part of a locale (e.g., "cu"),
  • keys that overlap, but don't fully align with features that we decided to let applications control via options (e.g., "co", "ks", "kc"),
  • keys that require special syntax support in the algorithms specified in the standard ("vt", "kr"). We therefore have to decide case by case which keys to support how, and can't leave this up to implementations.

The conformance clause allows implementations to support additional features through other mechanisms, such as additional properties on the options object.

Norbert