EcmaScript i18n API proposal

Nebojša Ćirić cira at
Fri Jun 11 09:13:02 PDT 2010

Hi Erik,
 see my responses inline.

On Wed, Jun 9, 2010 at 8:53 PM, Erik Corry <erik.corry at> wrote:

> 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.

I don't think one can expect the same set of locales across all JS engines.
If locale is not supported we should fall back to less specific one, with a

You are correct that there would be problems with compatibility across i18n
engines/libraries. ICU and Windows for example cover a lot of same locales,
but I think they name them in a different way. So an JS engine
implementation for ICU would differ from Windows or libc implementation
(when I say Windows implementation I mean using Windows calls to collate,
format... instead of a 3rd party library).

> From the proposal "The biggest problem is the size and complexity of
> data needed for collation process".  Given that this data is so huge,
> requiring all JS engines to include it for all locales ever invented
> doesn't sound good.

I think it's more the combination of algorithm complexity and data size that
prevents current implementation (closure, dojo) to offer collation. Also,
most of the locales have fairly small data set needed for the collation
(couple of kilobytes).
The biggest tables are for CJK, but they can be pruned down (with loss of

Android for example uses ICU in pruned down form - it supports only subset
of all ICU locales, and I think that's a usual approach for other features
in smartphone industry (including fonts).

Most of the browsers already have full access to the collation data (IE
through Windows API, Chrome through ICU...), so they wouldn't grow in size,
if JS engine were to use that data.

How about a system where locales can be described in a JSON based
> format and loaded into the running JS implementation?

There are some projects underway that would host/expose CLDR data as JSON
objects, but I am afraid that would bring more problems to the proposal:

1. We would need to agree on what goes into JSON (yet another standard?)
2. How would one use JSON data (rewrite parts of ICU or Windows i18n calls
to use JSON?)
3. Where to host JSON data, what if the user is offline?

> A positive thing about the proposal:  It doesn't, if I have understood
> it correctly, have a concept of a context-global locale setting.   No
> global state?  I like this.

Yes, it doesn't have global locale. You are free to create as many locales
per, say web page, and use them to sort, format and parse.

> 2010/6/9 Nebojša Ćirić <cira at>:
> > We would like to propose adding i18n API to the EcmaScript standard
> (either
> > as standard library or part of the language).
> > Our current proposal is at EcmaScript i18n API (open to edits). We will
> > migrate the document to the proper strawman wiki page as soon as we get
> > access to it.
> >
> > We feel that our current proposal represents the minimum set of objects
> and
> > methods needed, but we could certainly extend it to cover number/currency
> > formatting/parsing and possibly calendar support. Our main goal was to
> start
> > with minimal proposal and get early feedback from the community.
> > Please leave feedback to the proposed API either inside of the document
> or
> > post back to the mailing list.
> > --
> > Nebojša Ćirić
> >
> > i18n team,
> > Google Inc.
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at
> >
> >
> >

Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list