W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: Client side JavaScript i18n API

From: Robin Berjon <robin@berjon.com>
Date: Tue, 27 Apr 2010 15:38:21 +0200
Cc: marcosc@opera.com, public-webapps WG <public-webapps@w3.org>, Jungshik Shin <jshin@chromium.org>, public-i18n-core@w3.org
Message-Id: <424AB44C-58B6-4FCA-A186-F3B05D40E164@berjon.com>
To: Nebojša Ćirić <cira@chromium.org>

On Apr 26, 2010, at 20:49 , Nebojša Ćirić wrote:
> We have a first draft at
> http://docs.google.com/Doc?id=dhttrq5v_0c8k5vkdh (it has view/edit
> permissions).

That's interesting; personally I agree that this would be very useful in the browser. Small note: the API seems overly verbose at this point, why create a Locale object that seems to encapsulate little more than a string? The method names are also rather long.

I'm guessing that the idea is for Collator.compare() to return the values expected by JS sort()?

> 1. Namespace it should go under (document, window, window.i18n,
> window.navigator.i18n, i18n)

I would be tempted to say navigator, but really that's a bikeshed discussion. Getting the functionality right is far more important.

> Addison raises a valid question of having this API be part of
> JavaScript language itself, and I'll let Jungshik reply to that one.

If possible I tend to think that it's better to develop things independently — parts that don't need to be in core JS can be created outside. This doesn't meant that the APIs couldn't work in both browsers and CommonJS environment (in fact I believe that they should, simply with different entry points).

Robin Berjon - http://berjon.com/
Received on Tuesday, 27 April 2010 13:38:53 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:24 UTC