Bug 39451 – Client side JavaScript i18n API proposal

• Status: UNCONFIRMED
• Component: New Bugs

[Nebojša Ćirić]

This is a meta bug.

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).

In a Phase 1, we would start with limited WebKit implementation (locale implementation and date formatting). A Phase 2 would extend it to cover a large part of the ICU capabilities (collation, number/currency formatting, calendars...). We also want to collect information for what further phases could contain.

Proposed API - http://docs.google.com/Doc?id=dhttrq5v_0c8k5vkdh (open for edit).

Chromium bug related to this issue - http://code.google.com/p/chromium/issues/detail?id=28604.

W3C WebApps discussion we started - http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0301.html

[Jungshik Shin]

We're aware that not all Webkit ports use ICU, let alone non-Webkit Javascript engines/html+css rendering engines. Therefore, we'll be careful not to bind our APIs too tightly to ICU although our implementations (JSC and V8) will use ICU. 

Moreover, we do not expect to get the identical results across implementations because different (although comparable) locale data will be used. Rather, our goal is to have universal syntax and consistent support available for i18n of browser-based applications. However, we do expect different implementations to have comparable 'outputs' (of API calls). And, one potential (widely used) converging point would be CLDR (http://cldr.unicode.org )