Sorry g, forgot the Cc :-) On Thu, Jul 11, 2013 at 11:52 PM, Zbigniew Braniecki <[email protected] > wrote:
> ... > > 1) CanonicalizeLanguageTag [1] > > Because language tags come from developers and users, ability to > canonicalize them is crucial to us. ECMA 402 specifies this function and > all we need is to expose it in the API > I was thinking the same thing recently, at least for CanonicalizeLanguageTag. I was working with a platform that gave me a language tag in non-canonical form, meaning I had to either canonicalize it or rename my language files to match the same non-canonical form. Exposing it as `Intl.canonicalizeLanguageTag(tag)` seems like a good idea. > > 1.1) CanonicalizeLocaleList [2] > > That would also be nice to have :) > I don't think you could expose CanonicalizeLocaleList directly without altering it to return an array, you'd have to do something similar to step 5 of LookupSupportedLocales. I'm not sure we could change that function in the spec without other abstracts potentially being affected by tainted a Array.prototype, so I guess you'd need to specify a new function. In which case I'm wondering if maybe you'd be better off with `Intl.canonicalizeTags(tags)` which would cover both CanonicalizeLanguageTag() and CanonicalizeLocaleList(). 2) LookupAvailableLocales > > This function has almost identical heuristic to LookupSupportedLocales [3] > with a single difference being in step d). > > Replace: > - "If *availableLocale* is not *undefined*, then append *locale* to the > end of *subset*. " > with: > - "If *availableLocale* is not *undefined*, then append *availableLocale*to > the end of > *subset*. " > > The reason behind this is that localization frameworks need to choose the > >>available<< locales that closest match the user preferences. If we used > LookupSupportedLocales, we will receive the locales that user requested, > not ones that are available on the system. > In result on each of those, we'd have to call BestAvailableLocale [4] to > receive the tag name that we can pull resources for. > You can at least work around this for a single locale with Intl.NumberFormat(tag).resolvedOptions().locale. If you're already using the native localisation APIs, this might not be too much of a hindrance. What you're suggesting would need to be a function property of the constructors, e.g. `Intl.NumberFormat.availableLocalesOf()`. I'm not so sure this approach makes sense, though; wouldn't you still have a problem if your own API provided variant data where the system does not? > > With that one change, we are actually going to receive the right set of > language tags that we can then use to provide best language with fallbacks. > > Example implementation of this is L20n localization framework [5] which > copies Mozilla ECMA 402 code to expose the required functions and uses > custom function called prioritizeLocales to build the final locale fallback > chain. > > Comments? Feedback? Next steps? :) > > Cheers, > g. > -- > > Mozilla (http://www.mozilla.org) > > [1] http://ecma-international.org/ecma-402/1.0/index.html#sec-6.2.3 > [2] http://ecma-international.org/ecma-402/1.0/index.html#sec-9.2.1 > [3] http://ecma-international.org/ecma-402/1.0/index.html#sec-9.2.6 > [4] http://ecma-international.org/ecma-402/1.0/index.html#sec-9.2.2 > [5] https://github.com/l20n/l20n.js/blob/master/lib/l20n/intl.js#L431 > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
