On Mon, Jul 15, 2013 at 9:37 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Sun, Jul 14, 2013 at 5:20 AM, Andy Earnshaw <andyearns...@gmail.com> > wrote: > > 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. > > FWIW, exposing a new API because another API is broken in a particular > implementation is a known anti-pattern. We should fix problems at the > source. > Normally, I would agree. However, I was just using my scenario as an example for where exposing the API would have been useful for me. I can also think of a few other reasons: - Language tags can be in extlang form or canonical form. Depending on the source providing the language tag, it's not guaranteed to be the canonical form (extlang form can reinstate extlang subtags that were removed during canonicalisation). - The Internationalization API doesn't cover all aspects of its namesake, like translation, or formatting of postal codes or telephone numbers, as a few examples. Developer libraries could augment Intl with this data, so it would make lives easier if we exposed CanonicalizeLanguageTag to be used by such libraries. - Canonicalisation has at least a couple of optional steps (like normalising case or ordering variant subtags) so exposing a canonicalizing method would give developers a way to achieve consistency with the Internationalisation API. navigator.language isn't part of any stable specification, and even the current HTML 5.1 draft doesn't specify that tags should be returned in canonical form. Do you think it would be a good idea to raise an issue for this? Andy
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
