Thu Feb 11 18:09:36 PST 2010
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=
> as standard library or part of the language).
> Our current proposal is at=C2=A0EcmaScript i18n API=C2=A0(open to edits).=
> 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=
> methods needed, but we could=C2=A0certainly=C2=A0extend it to cover numbe=
> formatting/parsing and possibly calendar support. Our main goal was to st=
> with minimal proposal and get early feedback from the community.
> Please leave feedback to the proposed API either inside of the document o=
> 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
More information about the es-discuss