Re: Client side JavaScript i18n API

I agree with Cira on what he wrote in his two previous emails.

This email (as well as Addison's email this is responding to) was gotten off
public-webapps by mistake. So, I"m sending it again to the list. (sorry for
those who will receive two copies).

Jungshik

On Wed, Apr 28, 2010 at 1:47 PM, Nebojša Ćirić <cira@chromium.org> wrote:

> > 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.
>
> (resending from correct address, and cleaning up cc list).
>
> Our plan is to get WebKit approval as soon as we finalize this
> proposal (possibly Q2/Q3). We would do JavaScriptCore and V8
> implementations which would provide i18n API support for Chrome and Safari.
>
> Nebojsa
>
> >
> > 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>
> >
> > (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/
> >>
> >>
> >
> >
>