Discuss
  • Globalization API: supportedLocalesOf vs. getSupportedLocales

Globalization API: supportedLocalesOf vs. getSupportedLocales

# Norbert Lindenberg (13 years ago)

We invented the supportedLocalesOf method to let applications find out which of its requested locales are supported by the implementation of a service. A getSupportedLocales function that simply returns the locales that the implementation actually supports would be easier to understand, and could also be used by an application to implement its own locale negotiation. If I remember correctly, we chose not to offer getSupportedLocales primarily because the list returned might be huge - possibly over 1000 locales.

Maybe we should reconsider this? If an application really wants to have a list of 1000 locales, why not let it have it? If we want the ability to restrict the list, maybe there can be locale list as a parameter, and we return only those supported locales for which a prefix is on the locale list passed in? Or is there a more fundamental issue with getSupportedLocales?

Thanks, Norbert

# Shawn Steele (13 years ago)

There are 6000+ languages, and presumably any of them could be spoken in 200+ regions. There are additionally many variations of some of these languages. So that's not a thousand locales, that's over a million locales. Additionally there may be legitimate tags an application can support that it may have been originally designed for. (Perhaps a new language or region or variant) For an application that doesn't care much about the input locale, that's a lot of room for variety.

For applications that are only localized to a certain number of languages, then perhaps a getSupportedLocalizations() would be manageable. Again though, that scope is narrow and may be inappropriate to use in other contexts. Eg: my app is localized to only English, but someone uploaded French content, does that count?

# Norbert Lindenberg (13 years ago)

The set of locales returned by a getSupportedLocales method would have to reflect what's actually supported by a Collator, NumberFormat, or DateTimeFormat implementation, so I doubt we'd get to the millions. Many of these 6000+ languages are spoken by fewer than 200 people, so certainly not in 200+ regions. And even where languages are spoken in many countries, there may not be defined regional variants: For example, I speak German and live in the U.S., but I don't know of any defined de-US collation, number format, or date format (in a German context, I'd use de-DE).

If we let the application pass in the languages that it's interested in, that would probably be based on what a user has requested, so rarely more than 10 languages. If English, French, Spanish, and Arabic are on the list, you might still get over 100 locales, but that's about it.

Norbert

# Mark Davis ☕ (13 years ago)

Here's the problem.

The very same collator for "de" is valid for "de-DE", "de-AT", and "de-CH". In ICU you actually get a functionally-equivalent object back, no matter which of these you ask for.

However, that collator is also valid for other countries where 'de' is official: de-LU, de-BE, de-LI. Moreover, it is also valid for countries with sizable German speaking populations, including de-US and de-BR. And, it is also valid for German as used in any other country: "de-FR", ..., even "de-AQ".

That is, you would not expect any variation in collators between "de-DE" and "de-US". A German collator is equally valid for both. It is somewhat arbitrary where any given implementation draws the line in terms of indicating which locales a valid collator can be returned for.

Mark — Il meglio è l’inimico del bene — * * * [plus.google.com/114199149796022210033] *

# Shawn Steele (13 years ago)

Furthermore some implementations succeed for any input locale. In those cases DateTimeFormat could succeed for any input RFC4646 string. Many of those may fall back to non-specific data, but it is possible for getSupportedLocales to succeed for all of those.

It might be more practical to have a "getExplicitLocales" for the locales that the system has explicit information for, but I'm not sure how that'd be helpful. In Mark's case "de" might be the explicit locale that supports the collator but your application would somehow have to infer that "de" might also be useful for de-*. Furthermore, if Mark had a "de" collator, and generic Number/DateTimeFormats, but additional specific de-AT and de-CH Number formats, then he might return de, de-AT, and de-CH, but you'd still be left inferring that de supported de-DE by default (not necessarily a good assumption, particularly across implementations).

-Shawn

  blogs.msdn.com/shawnste

# Nicholas C. Zakas (13 years ago)

From a developer point of view, the last thing I'd want is to get a long array that I have to iterate through in order to start my work. I'd much rather say "hey, do you support this?" and have a method say "yes" or something similar. For instance:

//where xx, yy, zz are a prioritized list var supportedLocale = Locale.getSupportedLocale("xx", "yy", "zz");

if (supportedLocale == "zz") { //do something }