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