- From: Phillips, Addison <addison@lab126.com>
- Date: Tue, 20 Jul 2010 14:18:14 -0700
- To: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
FYI... Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs) Internationalization is not a feature. It is an architecture. -----Original Message----- From: Phillips, Addison Sent: Tuesday, July 20, 2010 2:18 PM To: 'es-discuss@mozilla.org' Subject: Internationalization proposal: some comments... Hi, I reviewed the thread at [1] and wanted to contribute a few comments on the strawman proposal at [2]. I think this effort is important. Many of us have struggled with the lack of ready internationalization support within ECMAScript and server-side or custom processing are both unsatisfying as a solution. During the W3C TPAC last year, some of us interested in this problem met with TC39 and made a number of suggestions [3] that I hope will be taken up for consideration---some of these are covered by this proposal. WRT the strawman, I had these comments: 1. The Locale class should have a matches() method or methods that permit locale/language negotiation to be implemented. RFC 4647 matching (either filtering or lookup) are far more common than pure equality checks. 2. Should there be a Locale.getDefault? 3. Should there be a TimeZone.getDefault()? 4. The Collator doesn't include rule-based collation? Is that planned for the future? 5. I know that other APIs are planned for the future, but message and number format are equally (often more) important than dates. I wouldn't want them omitted in an initial implementation. I hope to see progress on this work in the future. Regards, Addison [1] https://mail.mozilla.org/pipermail/es-discuss/2010-June/011380.html [2] http://docs.google.com/Doc?docid=0AW406aVETP5_ZGh0dHJxNXZfMGM4azV2a2Ro&hl=en [3] http://www.w3.org/International/wiki/JavaScriptInternationalization Addison Phillips Internationalization is not a feature. It is an architecture.
Received on Tuesday, 20 July 2010 21:18:49 UTC