No subject

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.

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

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.

2010/6/9 Neboj=C5=A1a =C4=86iri=C4=87 <cira at google.com>:
> We would like to propose adding i18n API to the EcmaScript standard (eith=
er
> as standard library or part of the language).
> Our current proposal is at=C2=A0EcmaScript i18n API=C2=A0(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 a=
nd
> methods needed, but we could=C2=A0certainly=C2=A0extend it to cover numbe=
r/currency
> formatting/parsing and possibly calendar support. Our main goal was to st=
art
> with minimal proposal and get early feedback from the community.
> Please leave feedback to the proposed API either inside of the document o=
r
> post back to the mailing list.
> --
> Neboj=C5=A1a =C4=86iri=C4=87
>
> i18n team,
> Google Inc.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>