Locale API

[zbran...@mozilla.com]

In the current API there's a set of methods that are related to language tag operations and language negotiation. They're all hidden within Intl API and not accessible from the outside.

I believe it's worth discussing an option of not only making them public, but also moving them out of an Intl object because although they are used by Intl, they are not Intl specific and are useful for other APIs as well. Three APIs that I see specifically are:

*) L10n libraries
*) Keyboards/Dictionaries/Speech-data packs etc.
*) Vanilla language selectors (for when the l10n happens on the server side)

I suggest separating them out in form of a new Locale object that will, initially have the following methods:

1) IsStructurallyValidLanguageTag(string)

Tests if the string is a valid language tag

2) CanonicalizeLocaleList(array)

Creates a valid normalized list of language tags out of an array of strings

3) SupportedLocales(availableLocales, requestedLocales, options)

Returns the subset of requestedLocales for which availableLocales has a matching locale.

4) PrioritizeAvailableLocales(availableLocales, requestedLocales, [defaultLocale], options)

Returns the subset of availableLocales, that match any of the locales in requestedLocales ordered by the requestedLocales list.
If defaultLocale is provided and is not present in the requestedLocales, it is added at the end of the list.


The last method is basically what l10n needs for language negotiation. It has a set of resources for a number of locales (example: ['fr', 'de', 'it', 'en-US'])
and it has to negotiate it against languages requested by the user (example: ['pl', 'de', 'fr']).

The result of that operation should be a list of available locales in prioritized by requestedLocales (example: ['de', 'fr']). This is the fallback chain that will be used by the localization library to load
its resources. defaultLocale may serve as a last resort in case no locales overlap between available and requested or for another reason loading resources in all other languages fails.

Thoughts?
zb.
Ecma issue: https://github.com/tc39/ecma402/issues/5

[Rick Waldron]

> moving them out of an Intl object

To where? These aren't going to be exposed on the global object under any circumstance. 

Rick

--
You received this message because you are subscribed to the Google Groups "JavaScript Globalization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javascript-globali...@googlegroups.com.
To post to this group, send email to javascript-g...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/072e19d8-631f-42e9-9c0e-31c38b022953%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[zbran...@mozilla.com]

On Friday, September 18, 2015 at 11:58:04 AM UTC-7, Rick Waldron wrote:

> moving them out of an Intl object

To where?

My idea was to have a global object Locale, but I can see it being Intl.Locale.
 

These aren't going to be exposed on the global object under any circumstance. 

What's the reasoning? (I'm genuinely unaware of  any limitations).

zb.

[Nebojša Ćirić]

We were talking about Intl.Locale object during work on initial proposal, but didn't have compelling reason to introduce it. It would be good only for hanging those BCP47 parsing methods on, but then we could just expose methods for that in Intl.

--

You received this message because you are subscribed to the Google Groups "JavaScript Globalization" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javascript-globali...@googlegroups.com.
To post to this group, send email to javascript-g...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/javascript-globalization/4d5ab838-e170-450e-b1c7-0e46a73c4206%40googlegroups.com.