Internationalization: Issues with upgrading to UTS 35 version 21
addison at lab126.com
Thu Aug 2 22:33:14 PDT 2012
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.
> >>> 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
More information about the es-discuss