Internationalization API issues and updates

Norbert Lindenberg ecmascript at norbertlindenberg.com
Sun Apr 29 18:04:11 PDT 2012


A few replies below.

Norbert


On Apr 17, 2012, at 12:20 , Phillips, Addison wrote:

> A few comments follow.
>  
> Addison
>  
> Addison Phillips
> Globalization Architect (Lab126)
> Chair (W3C I18N WG)
>  
> Internationalization is not a feature.
> It is an architecture.
>  
>  
>  
> On Mar 26, 2012 4:59 PM, "Norbert Lindenberg" <ecmascript at norbertlindenberg.com> wrote:
> While everybody is reviewing the draft specification of the ECMAScript Internationalization API [1] in preparation for this week's TC 39 meeting, here are a few issues that have come up, with proposed resolutions:
> 
> 
> Issue 1, IsWellFormedLanguageTag (6.2.2), raised by Allen:
> 
> The specification referenced here, RFC 5646 section 2.1, says nothing about the case of duplicate extension subtags (example: the duplicate -u- in "de-u-nu-latn-u-ca-gregory"), although RFC 5646 section 2.2.9 and section 3.7 say tat duplicate extension subtags are invalid. The ResolveLocale abstract operation (Globalization API, 9.2.1) will only consider the first extension subtag sequence it sees, and ignore others, without giving applications any hint as to what's going on.
>  
> AP> Probably a reasonable way to handle that. I assume that you actually mean, btw, “ResolveLocale … will only consider the first extension subtag sequence it recognizes”. E.g. it would ignore the newly-added “-t-“ extension and find the “-u-“ in a tag like “en-us-t-something-u-ca-gregori”

Yes. Fortunately, this glitch only occurs in our discussion - the spec clearly refers to "Unicode Locale Extension Sequences", which are specified with the singleton "u".

> Should IsWellFormedLanguageTag be enhanced to check for duplicate extension subtags? And then probably also duplicate variant subtags?
>  
> AP> Strictly speaking, according to BCP 47, the term “well-formed” encompasses *only* the check against the ABNF, which does not include these checks.

I changed the spec to use the term "structurally valid", which you use below.

> The one thing I'm sure we don't want is validation against the IANA Language Subtag Registry.
>  
> AP> That’s “valid”, not “well-formed” in BCP 47 parlance. I agree with this.
> 
> 
> My proposed resolution: Add checking for duplicate extension subtags and duplicate variant subtags, and throw exception if they exist.
>  
> AP> … and actually I agree with this. Structural validity checking seems like a reasonable and useful addition.



More information about the es-discuss mailing list