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. /be > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
