Sorry g, forgot the Cc :-)

On Thu, Jul 11, 2013 at 11:52 PM, Zbigniew Braniecki <zbraniecki at mozilla.com
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130713/a1e677c8/attachment.html>

On Thu, Jul 11, 2013 at 11:52 PM, Zbigniew Braniecki <zbraniecki at mozilla.com> 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?