Globalization API: supportedLocalesOf vs. getSupportedLocales

Nicholas C. Zakas standards at nczconsulting.com
Tue Nov 29 13:22:37 PST 2011 

 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
}

-N

On 11/29/2011 9:22 AM, Shawn Steele wrote:
>
> 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.davis at gmail.com [mark.edward.davis at gmail.com] on 
> behalf of Mark Davis ? [mark at 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 
> <ecmascript at norbertlindenberg.com 
> <mailto:ecmascript at 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-bounces at mozilla.org
>     <mailto:es-discuss-bounces at mozilla.org>
>     [mailto:es-discuss-bounces at mozilla.org
>     <mailto:es-discuss-bounces at 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 at mozilla.org <mailto:es-discuss at mozilla.org>
>     > https://mail.mozilla.org/listinfo/es-discuss
>     >
>     >
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111129/c58219c4/attachment-0001.html>

More information about the es-discuss mailing list