> On Thu, Jul 11, 2013 at 11:52 PM, Zbigniew Braniecki <zbraniecki at mozilla.com  <https://mail.mozilla.org/listinfo/es-discuss>
> >/  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.

Only exposing CanonicalizeLanguageTag does not seem useful to me without 
having access to IsStructurallyValidLanguageTag. Most likely a combined 
IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is 
necessary/wanted for most use cases.


>
> >/
> />/  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().

I don't see why you'd need to change CanonicalizeLocaleList at all. Just 
let it return the internal list as-is, and then define 
`Intl.canonicalizeLocaleList` like so:

Intl.canonicalizeLocaleList(locales):
1. Let canonicalizedLocaleList be the result of 
CanonicalizeLocaleList(locales).
2. ReturnIfAbrupt(canonicalizedLocaleList).
3. Return CreateArrayFromList(canonicalizedLocaleList).

(ReturnIfAbrupt and CreateArrayFromList are defined in ES6 as internal 
abstract operations.)

It also needs to be considered whether the duplicate removal in 
CanonicalizeLocaleList creates any issues for users of a potential 
`Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function.


- André
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130713/fd4d10f1/attachment.html>

> 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.

Only exposing CanonicalizeLanguageTag does not seem useful to me without 
having access to IsStructurallyValidLanguageTag. Most likely a combined 
IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is 
necessary/wanted for most use cases.

> 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().

I don't see why you'd need to change CanonicalizeLocaleList at all. Just 
let it return the internal list as-is, and then define 
`Intl.canonicalizeLocaleList` like so:

Intl.canonicalizeLocaleList(locales):

1. Let canonicalizedLocaleList be the result of CanonicalizeLocaleList(locales).
2. ReturnIfAbrupt(canonicalizedLocaleList).
3. Return CreateArrayFromList(canonicalizedLocaleList).

(ReturnIfAbrupt and CreateArrayFromList are defined in ES6 as internal abstract operations.)

It also needs to be considered whether the duplicate removal in 
CanonicalizeLocaleList creates any issues for users of a potential 
`Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function.