Hi all,

Currently, ECMA 402 specifies a pretty nice language negotiation 
algorithm... and keeps it private.

While working on l10n frameworks, we need to be able to negotiate 
between at least two parties - application and user preferences, in the 
very same way I18n API does, so if we could get the language negotiation 
bits exposed, we could just use that, and keep language choices between 
l10n and i18n in sync.

So, what do we need?

While working on L20n we identified two functions as crucial:

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

1.1) CanonicalizeLocaleList [2]

That would also be nice to have :)

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130711/487d916b/attachment.html>

Currently, ECMA 402 specifies a pretty nice language negotiation 
algorithm... and keeps it private.

While working on l10n frameworks, we need to be able to negotiate 
between at least two parties - application and user preferences, in the 
very same way I18n API does, so if we could get the language negotiation 
bits exposed, we could just use that, and keep language choices between 
l10n and i18n in sync.

So, what do we need?

While working on L20n we identified two functions as crucial:

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

1.1) CanonicalizeLocaleList [2]

That would also be nice to have :)

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.

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? :)

[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

Currently, ECMA 402 specifies a pretty nice language negotiation 
algorithm... and keeps it private.

While working on l10n frameworks, we need to be able to negotiate 
between at least two parties - application and user preferences, in the 
very same way I18n API does, so if we could get the language negotiation 
bits exposed, we could just use that, and keep language choices between 
l10n and i18n in sync.

So, what do we need?

While working on L20n we identified two functions as crucial:

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

1.1) CanonicalizeLocaleList [2]

That would also be nice to have :)

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.

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? :)

[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