RE: Client side JavaScript i18n API

(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:robin@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=9D@poing.nachbaur.
> com; _?= 申政湜)"
> Cc: Phillips, Addison; marcosc@opera.com; Nebojša Ćirić; public-
> webapps WG; public-i18n-core@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/

> 
>

Received on Tuesday, 27 April 2010 16:13:53 UTC