Referring to the process: Trying to get effective and useful internationalization supported in ECMAScript has been a fruitless process (see Markus's memo of some seven or eight years ago). It might be possible to get needed changes if one were to spend enough (a huge amount of) time with the ECMA committee, but even then, the process will take a long time.
A better way would be to develop and standardize API in the W3C (or some other suitable venue), aimed at developers who need internationalization on the web in a more timely fashion. And in a way, one could view intl as an (important) library layered on top of the basic language. We could make sure that ECMA is in the loop, and if some of those changes are picked up in ECMAScript later on, that wouldn't be so bad (the APIs could just be converted into wrappers at that point). Mark — Il meglio è l’inimico del bene — 2010/4/27 Phillips, Addison <addi...@lab126.com> > (personal response) > > Speed is a problem with the ECMAScript process. It would probably be > several years (based on their testimony) before ES 6.0 would be complete. > That doesn't mean we have to wait for the rest of the 6.0 paint to dry, > though. The standard can take the form of recognizing what has already been > agreed elsewhere. > > My concern about making a separate API or part of CommonJS is that there > *do* exist methods (toLocaleString, sort, etc.) that promise (but do not > deliver) internationalization in the core. These methods could be extended > in a backwards compatible fashion and result in a low-learning curve means > for scripters to get what they need. > > A locale facet in the language would also enable developers to rely on the > locale data being present for development of their own solutions. This could > reside in CommonJS (along with Time Zone, the other missing bit). The goal > would be to have universal, consistent support for the syntax (even if, say, > Microsoft's locale data varies from say Google's). > > A project to implement this could go quite fast, I think, but would require > agreement by the major browser vendors and a place to do the work. We could > do this at W3C, but I think ECMA should be involved from early on. We have > had success in the International activity with Task Forces, although we > would need some chartering work. Webapps might also be a good home for this > work. > > Addison > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > > > -----Original Message----- > > From: Robin Berjon [mailto:ro...@berjon.com] > > Sent: Tuesday, April 27, 2010 6:49 AM > > To: =?utf- > > 8?q?=22jungshik_shin_=28=ec=8b=a0=ec=a0=95=ec=8b...@poing.nachbaur. > > com; _?= 申政湜)" > > Cc: Phillips, Addison; marc...@opera.com; Nebojša Ćirić; public- > > webapps WG; public-i18n-c...@w3.org > > Subject: Re: Client side JavaScript i18n API > > > > On Apr 27, 2010, at 00:11 , Jungshik Shin (신정식, 申政湜) wrote: > > > Yes, I agree. Now it's not just web sites but also local > > "apps/widgets/browser extensions" written in HTML/JS/CSS are > > affected. > > > > As a side note it's interesting to note that you're taking widgets > > into account, I didn't know you were interested in those. > > > > > First of all, I'm not sure of the wisdom of making a large set of > > i18n APIs (locale, collation, formatting - number, date, message -, > > and more) a part of 'the language' proper. Javascript does not > > have a concept of standard library. If it had, wouldn't everybody > > agree that this should be a part of that library rather than the > > 'language proper'? Javascript does not have that notion. Does it > > mean we can/should add a slew of APIs to 'the language proper'? > > > > No, I think that we should operate on the assumption that JS's > > standard library is CommonJS and the browser (merging the two to a > > point would be great, but that's another topic). I would think that > > making an API that can work for both shouldn't be excessively hard > > in this case. > > > > > Secondly, I'm worried about the pace of the language > > standardization process. I have an 'impression' (which may be > > totally off the mark or outdated) that the process is rather slow. > > On the other hand, WebApps WG has been moving fast. We'd like to > > start with a working prototype of a small subset of APIs fairly > > soon and iterate through WG to fix/refine/expand. > > > > Standards can be fast and they can be slow — it all depends on how > > they're made. IME fast standards depend on: > > > > 1) Scoping: defining the scope of v1 to be as small as possible > > while still being useful and then being a fascist about it. > > 2) Manpower: writing specifications, answering comments, writing > > tests all take time. More time than you think they will (a standard > > has to be of much higher quality than typical technical > > documentation). > > 3) Implementation & Usage: as tight as possible a feedback loop > > with implementers and developers speeds things up. > > > > If you have the means to commit all three, you'll probably go > > fast :) > > > > -- > > Robin Berjon - http://berjon.com/ > > > > > >
