Re: [webkit-dev] Client side JavaScript i18n API proposal
Hi Oliver, thanks for quick reply. See my comments below. On Thu, May 20, 2010 at 4:53 PM, Oliver Hunt oli...@apple.com wrote: It seems like the majority of this belongs in EcmaScript directly rather than being restricted to web-oriented uses of ES. This is what Jungshik replied to the similar question on webapps list: 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. i18n support is usually done through a library (e.g. ICU4C), only basic things are built into the language itself, like support for UTF-16/32 strings. I'm also unsure of the relevance of CommonJS to either WebAPI or ES as CommonJS is not part of either standards body. For example the use of require implies making CommonJS modules part of WebAPI, rather than any of the current modules proposals working through TC39. My understanding is that CommonJS (formerly ServerJS) is gearing towards becoming a standard library for ES. We mention it just to show how our API can be implemented in CommonJS by simply replacing namespace from say window.navigator.locale to some_module.locale. -- Nebojša Ćirić ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Client side JavaScript i18n API proposal
There are a number of areas where JavaScript i18n APIs are deficient. Our goal is to develop better client-side i18n API for JavaScript, and eliminate need for big JavaScript libraries or server side processing. Eventually, we want to make them a part of WebAPI (worked on by WebApp WG). Our proposal to API is up at http://docs.google.com/Doc?id=dhttrq5v_0c8k5vkdh In a Phase 1, we would start with limited WebKit implementation (locale implementation and date formatting). A Phase 2 would extend it to cover collation, number/currency formatting, calendars... See bug https://bugs.webkit.org/show_bug.cgi?id=39451 for details (proposed API, motivation, related chromium bug and WebApps thread we started). We would like to start prototyping Locale part of the API in next couple weeks, both for JSC and V8, and we would appreciate your input wrt. proposed API. We'll continue working with WebApps group on standardizing the API but we would like to keep moving forward with the implementation too, thus cross-posting on webkit-dev. -- Nebojša Ćirić ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Client side JavaScript i18n API proposal
It seems like the majority of this belongs in EcmaScript directly rather than being restricted to web-oriented uses of ES. I'm also unsure of the relevance of CommonJS to either WebAPI or ES as CommonJS is not part of either standards body. For example the use of require implies making CommonJS modules part of WebAPI, rather than any of the current modules proposals working through TC39. --Oliver On May 20, 2010, at 4:45 PM, Nebojša Ćirić wrote: There are a number of areas where JavaScript i18n APIs are deficient. Our goal is to develop better client-side i18n API for JavaScript, and eliminate need for big JavaScript libraries or server side processing. Eventually, we want to make them a part of WebAPI (worked on by WebApp WG). Our proposal to API is up at http://docs.google.com/Doc?id=dhttrq5v_0c8k5vkdh In a Phase 1, we would start with limited WebKit implementation (locale implementation and date formatting). A Phase 2 would extend it to cover collation, number/currency formatting, calendars... See bug https://bugs.webkit.org/show_bug.cgi?id=39451 for details (proposed API, motivation, related chromium bug and WebApps thread we started). We would like to start prototyping Locale part of the API in next couple weeks, both for JSC and V8, and we would appreciate your input wrt. proposed API. We'll continue working with WebApps group on standardizing the API but we would like to keep moving forward with the implementation too, thus cross-posting on webkit-dev. -- Nebojša Ćirić ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
