EcmaScript i18n API proposal

Mark Davis ☕ mark at
Thu Jun 10 17:46:06 PDT 2010

*Re the following message:*
It is clearly expected that the number of locales available on any
particular device may be limited; a smartphone, for example, might have very
few installed, or have limited services for those it does have installed. With
the locale model, implementations are expected to use "the best match". That
is, for a given service (like collation) if there is no support for German
phonebook, then it would fallback to German; if there is no support for
German then it will fall back to some default locale, such as English. The
features of a locale are best thought of as requests, to be used wherever

That being said, you'd be surprised at how many implementations could easily
support the example German phonebook through underlying OS or library
services, since it has been a standard option on Windows for quite a
while (locale
0x10407 = German with phonebook sort), and in ICU -- thus in the Mac OS, on
Google servers, etc.

*Erik Corry* erik.corry at
*Wed Jun 9 11:53:14 PDT 2010*

   - Previous message: EcmaScript i18n API proposal <011388.html>
   - *Messages sorted by:* [ date ] <date.html#11384> [ thread
    [ subject ] <subject.html#11384> [ author ] <author.html#11384>


On the face of it this proposal introduces a huge new area of
incompatibilities between engines in terms of both which locales are
supported and the details of the locales.  The example (German
phonebook locale) is suitably obscure as to illustrate the
hopelessness of expecting JS engines to contain all thinkable locales.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list