- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 27 Apr 2010 15:48:52 +0200
- To: "Jungshik Shin (신정식@poing.nachbaur.com, 申政湜)" <jshin@chromium.org>
- Cc: "Phillips, Addison" <addison@lab126.com>, "marcosc@opera.com" <marcosc@opera.com>, Nebojša Ćirić <cira@chromium.org>, public-webapps WG <public-webapps@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
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/
Received on Tuesday, 27 April 2010 13:49:27 UTC