Re: Client side JavaScript i18n API

Hi Addison,

Thank you for your interest and reminder about the past effort on enhancing
i18n support in  ECMAScript. I mistakenly thought it's limited to non-BMP
character support.

On Mon, Apr 26, 2010 at 8:27 AM, Phillips, Addison <addison@lab126.com>wrote:
>
>
> I think that Internationalization support in JavaScript has been too long
> overlooked and represents a barrier to development of multilingual web
> sites.
>

Yes, I agree. Now it's not just web sites but also local
"apps/widgets/browser extensions" written in HTML/JS/CSS are affected.


> The Internationalization WG actually approached the ECMASCript folks about
> providing for international support in the JavaScript language. We feel that
> explicit support in the language is important, and the ECMAScript people we
> met with at W3C TPAC 2009 seemed open to our suggestions.
>

I have two concerns about taking that direction:

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'?


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.

 In addition to the above concern, this is another reason we proposed i18n
APIs to WebApps WG instead of proposing that they be a part of the
language.



>
> An outline of the requirements we presented to them can be found here:
>
>   http://www.w3.org/International/wiki/JavaScriptInternationalization


There's no doubt that some items in the document have to be dealt with in
ECMAStandard - those involving adding support for non-BMP Unicode
characters.  For others, I have some concerns as I wrote above. What would
you say about them?


>
> Based on our conversation with the ECMA working group, we should be
> prepared to make proposals and work with them on language standardization in
> the near future. If functional implementations can be demonstrated, that
> would probably be helpful as well.
>
> If you would like, I would be happy to devote some time at an upcoming I18N
> Core WG teleconference to discuss this. You might also bring this
> conversation to the www-international@w3.org mailing list.
>
>
How come I forgot about that? :-)  I'm afraid cross-posting wouldn't work
very well. Anyway, I'll bring up an issue there, too.


Thank you for your reminder about existing JS i18n efforts and interest,

Jungshik




>
>
> > -----Original Message-----
> > From: public-i18n-core-request@w3.org [mailto:public-i18n-core-
> > request@w3.org] On Behalf Of Robin Berjon
> > Sent: Monday, April 26, 2010 2:55 AM
> > To: marcosc@opera.com
> > Cc: Nebojša Ćirić; public-webapps WG; Jungshik Shin; public-i18n-
> > core@w3.org
> > Subject: Re: Client side JavaScript i18n API
> >
> > On Apr 26, 2010, at 11:38 , Marcos Caceres wrote:
> > > 2010/4/23 Nebojša Ćirić <cira@chromium.org>:
> > >>  We would like to propose an API for locale-based collation,
> > >> date/number formatting, ... Does anybody else think this would
> > benefit
> > >> the authors?
> > >>
> > >>  We would be happy to answer questions to what problems are we
> > trying
> > >> to solve, and how.
> > >
> > > I think the DAP guys are trying to handle some of this in their
> > > Calendar API.
> >
> > Hmm no we're not — we're simply looking at ways of handling the
> > massive number of different calendars that users could want to use.
> >
> > Nebojša: I think that there could be value in the sort of API that
> > you describe, but it'd be easier to answer your question if we
> > could see it :)
> >
> > --
> > Robin Berjon - http://berjon.com/
> >
> >
> >
>
>