- From: Nebojša Ćirić <cira@chromium.org>
- Date: Wed, 28 Apr 2010 11:51:14 -0700
- To: Robin Berjon <robin@berjon.com>
- Cc: marcosc@opera.com, public-webapps WG <public-webapps@w3.org>, Jungshik Shin <jshin@chromium.org>, public-i18n-core@w3.org
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:47 UTC