Globalization API Feedback - moar!

Brendan Eich brendan at
Thu Dec 1 11:53:35 PST 2011

On Nov 30, 2011, at 11:37 PM, Brendan Eich wrote:

> On Nov 30, 2011, at 10:25 PM, Anton Yatsenko wrote:
>> In case I've missed point — sorry.
> There are several points. How one gets the Globalization "module" is one, but the bigger points at issue involve API parameterization, overhead, and style issues.

Also, critically (Shawn Steele's latest post, cited in full below, hit this point) "support inference" or in general, whether and how fallback works.


> 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
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list