RE: Client side JavaScript i18n API

Hi,

I think that Internationalization support in JavaScript has been too long overlooked and represents a barrier to development of multilingual web sites.

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.

An outline of the requirements we presented to them can be found here:

   http://www.w3.org/International/wiki/JavaScriptInternationalization


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.

Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.


> -----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/

> 
> 
>

Received on Monday, 26 April 2010 15:28:01 UTC