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 http://blogs.msdn.com/shawnste ________________________________ From: mark.edward.da...@gmail.com [mark.edward.da...@gmail.com] on behalf of Mark Davis ☕ [m...@macchiato.com] Sent: Monday, November 28, 2011 6:28 PM To: Norbert Lindenberg Cc: Shawn Steele; Eric Albright; es-discuss Subject: Re: Globalization API: supportedLocalesOf vs. getSupportedLocales 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 — [https://plus.google.com/114199149796022210033] On Tue, Nov 29, 2011 at 02:15, Norbert Lindenberg <ecmascr...@norbertlindenberg.com<mailto:ecmascr...@norbertlindenberg.com>> wrote: 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 On Nov 28, 2011, at 17:37 , Shawn Steele wrote: > 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? > > -Shawn > > -----Original Message----- > From: es-discuss-boun...@mozilla.org<mailto:es-discuss-boun...@mozilla.org> > [mailto:es-discuss-boun...@mozilla.org<mailto:es-discuss-boun...@mozilla.org>] > On Behalf Of Norbert Lindenberg > Sent: Monday, November 28, 2011 5:30 PM > To: Eric Albright; Peter Constable; Shawn Steele > Cc: es-discuss > Subject: Re: Globalization API: supportedLocalesOf vs. getSupportedLocales > > 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 > > > On Nov 21, 2011, at 11:12 , Nicholas C. Zakas wrote: > >> 2. supportedLocalesOf >> >> I find this method name strange - I've read it several times and am still >> not sure I fully understand what it does. Perhaps "getSupportedLocales()" is >> a better name for this method? (I always prefer methods begin with verbs.) > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
