- From: 신정식, 申政湜 <jshin@chromium.org>
- Date: Mon, 26 Apr 2010 15:11:28 -0700
- To: "Phillips, Addison" <addison@lab126.com>
- Cc: Robin Berjon <robin@berjon.com>, "marcosc@opera.com" <marcosc@opera.com>, Nebojša Ćirić <cira@chromium.org>, public-webapps WG <public-webapps@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
- Message-ID: <u2p72299d311004261511g8a7a015w59adbb20c3b61bd6@mail.gmail.com>
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/ > > > > > > > >
Received on Thursday, 29 April 2010 08:43:51 UTC