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:* [email protected] [[email protected]] on
behalf of Mark Davis ? [[email protected]]
*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
<[email protected]
<mailto:[email protected]>> 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: [email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] 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
> [email protected] <mailto:[email protected]>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
