Re: Client side JavaScript i18n API

On Tue, Apr 27, 2010 at 6:38 AM, Robin Berjon <> wrote:
> Hi,
> On Apr 26, 2010, at 20:49 , Nebojša Ćirić wrote:
>> We have a first draft at
>> (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?

We were trying to match ICU API in most cases.

Having a Locale object vs. plain string has couple of benefits:
- Easier to extend in the future, without changing the API
- You validate locale once, and then pass it around to API methods
instead of checking the locale string on each function call
- Locale object can have getLocale, getLanguage, getCountry... methods.

I agree it would make simple, one off operation more cumbersome, since
you need 3 steps:

var locale = createLocale('sr');
var formatter = createDateTimeFormatter(locale[, format])
var date = formatter.format(Date[, format])

But I expect locale to be reused throughout the document, as well as
the formatters/collators.
We could possibly offer shorthand for cheap operations, like
formatDate(Date, format, Locale), like Dojo does.

> The method names are also rather long.

Do you mean createCollator, createLocale methods? I am open to
suggestions, but these are standard factory names.

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

That's correct.

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

I agree. Namespace can be changed at any point.

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

It seems CommonJS is still not ready for browser side application
(because of the way it loads the modules - see links [1, 2, 3]). One
still needs to contact server to grab modules, and they can be
JavaScript only, which can be a problem for collation for example
(size, complexity).

I agree we should try to define API that would work with browser and
CommonJS (with separate implementation).

1 -
2 -
3 -

Received on Wednesday, 28 April 2010 18:51:47 UTC