Re: Client side JavaScript i18n API

On Tue, Apr 27, 2010 at 6:38 AM, Robin Berjon <robin@berjon.com> wrote:
> Hi,
>
> 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?

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 Collator.compare() 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 - http://tagneto.blogspot.com/2009/11/javascript-module-loading-browser-and.html
2 - http://stackoverflow.com/questions/1999974/will-existing-javascript-frameworks-incorporate-commonjs
3 - http://pmuellr.blogspot.com/2010/02/modjewel-020-commonjs-require-function.html

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