Internationalization: Issues with upgrading to UTS 35 version 21
ecmascript at norbertlindenberg.com
Fri Aug 3 10:49:44 PDT 2012
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.
On Aug 2, 2012, at 22:33 , Phillips, Addison wrote:
> 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).
>> -----Original Message-----
>> From: Norbert Lindenberg [mailto:ecmascript at norbertlindenberg.com]
>> Sent: Thursday, August 02, 2012 10:08 PM
>> To: Phillips, Addison
>> Cc: Norbert Lindenberg; Gillam, Richard; es-discuss
>> Subject: Re: Internationalization: Issues with upgrading to UTS 35 version 21
>> "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.
>> On Jul 19, 2012, at 16:11 , Phillips, Addison wrote:
>>>>> 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.
>>>> 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.
More information about the es-discuss