UPDATE: Latest Proposal - Nov 2015

I started working on a spec and polyfill for Intl.Locale API.

I should have some proposal for this next week. Currently I have five functions on it:

• isStructurallyValidLanguageTag(locale)
• canonicalizeLocaleList(locales)
• resolveLocale(availableLocales, requestedLocales, options, relevantExtensionKeys, localeData)
• prioritizeAvailableLocales(availableLocales, requestedLocales, defaultLocale)
• getDirection(locale)

The rationale for those five are:

• isStructurallyValidTag
  This allows testing language tag for sanitation/validation purposes.
• canonicalizeLocaleList
  This is the core function allowing all language negotiation operations
• resolveLocale

this exposes the core function used by all Intl formatters that allows people to write their own custom formatters or polyfills.

• prioritizeAvailableLocales

This is basic language negotiation function for all localization libraries. It takes requestedLocales list (navigator.languages or custom), availableLocales (app provided locales), and a fallback defaultLocale (default app locale, not default host env locale) and returns the list of prioritized available locales that best matches user requested locales.

• getDirection

Simple function allowing l10n libraries to set html.dir based on their negotiated locale.

@caridy - One question I'd like to get help with is about using Set instead of Array. In all cases where we carry a list of locales, we always want it deduplicated and Set does just that. It would be sweet to use it instead of an Array, but it's API seems to be significantly less user friendly than that of the Array - it's impossible to just retrieve locales[0], it's not easy to map etc.
Should I stick to Array or try to use Set?