RE: Client side JavaScript i18n API

I agree (and am empowered by the I18N WG to say so). I don’t think we need to saddle the I18N efforts with the TC39 process but rather that what we do be compatible and consistent with internationalization changes in ES6.0 that TC39 eventually really *MUST* take up---that we push forward with them appropriately and consistently (I’m thinking here more of things like supplementary character support, but also that “toLocaleString()” is consistent with how internationalization is specified).

A much bigger concern to me is not TC39’s involvement but rather that we get the major vendors involved and committed. To that end, I would be happy to help chartering efforts within the International Activity (although I18N Core WG cannot host this effort directly). Alternatively, the I18N WG supports chartering this work as part of Webapps.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Behalf Of Mark Davis ?
Sent: Wednesday, April 28, 2010 12:14 PM
To: Phillips, Addison
Cc: Robin Berjon; "Jungshik Shin (신정식@poing.nachbaur.com"<?utf-8?Q22Jungshik_Shin_=28=EC=8B=A0=EC=A0=95=EC=8B=9D@poing.nachbaur.com>, _?= 申政湜)"; marcosc@opera.com; Nebojša Ćirić; public-webapps WG; public-i18n-core@w3.org
Subject: Re: Client side JavaScript i18n API

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 <addison@lab126.com<mailto:addison@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:robin@berjon.com<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<mailto:marcosc@opera.com>; Nebojša Ćirić; public-
> webapps WG; public-i18n-core@w3.org<mailto: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/

>
>