On Sun, Jul 14, 2013 at 2:07 AM, Norbert Lindenberg < ecmascr...@lindenbergsoftware.com> wrote:
> > CanonicalizeLanguageTag isn't even defined for non-structurally valid > language tags. That's why I meant a combined IsStructurallyValidLanguageTag > + CanonicalizeLanguageTag function is more useful than access to the bare > CanonicalizeLanguageTag function. > > Correct. As currently specified, the CanonicalizeLanguageTag abstract > operation assumes that its input is a String valueI'm not too sure about > the that's a structurally valid language tag. An API cannot make such > assumptions - it has to be ready to deal with any input, as well as the > absence of input. It has to do something like the steps in > CanonicalizeLocaleList 8.c.ii-iv before calling the current > CanonicalizeLanguageTag. > You're both right, it assumes a string and doesn't check validity. That didn't occur to me, it's been a few months since my implementation. > Before we get too much into spec details: Do others believe that exposing > API as proposed by Zbigniew would be useful? > I certainly do, at least for Canonicalize-. I've come across one user agent that returns `navigator.language` in non-canonical form which presented a small problem for data I had stored with canonical file names. This was a WebKit based Smart TV platform from 2012, so it was fairly recent, there could be other platforms or frameworks that do the same. As for LookupAvailableLocales, there might be a problem with Zbigniew's vision of it as any tags would be returned without extensions. I'm not sure if this is something that we'd need to worry about, though. Andy
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
