Globalization API: Locale list argument

Norbert Lindenberg ecmascript at norbertlindenberg.com
Sat Nov 19 19:00:46 PST 2011


I'm not clear on where a global locale list would be maintained, and without a global locale list I don't think moving the locale list into options would be a good idea.


Candidates I remember being proposed for maintaining a global locale list:

- The Globalization object. This would not allow separation of the locales of different page components (e.g., embedded apps), and create a communication channel that Mark Miller doesn't like.

- An object initialized from a module. This would allow separation of different contexts, but I don't see how a constructor (e.g. Collator) or a global function (e.g., Date.prototype.toLocaleString) would find the right such object for a context.


Now, while I don't see how to solve this with the facilities provided by the ECMAScript standard, some JavaScript libraries and frameworks have already solved this problem. For example:

- The YUI library allows the creation of sandbox environments using separate YUI objects. Each YUI object can have a "lang" configuration setting with a BCP 47 language priority list, which is used in loading the resource bundles for localizable modules.

- The OpenSocial spec provides gadgets with a user preferences object, gadgets.Prefs, which includes an ISO 639 language code and an ISO 3166 country code. The i18n module uses these to determine appropriate number and date formats.

- dojo's djConfig contains locale (default language) and extraLocale (additional languages) properties, which are used by the requireLocalization function to load resource bundles.


So it seems to me that it would be better to leave maintenance of locale lists to these libraries and frameworks, rather than duplicating the functionality in ECMAScript. They can then offer wrapper functions that call ECMAScript functions with the locale list filled in.

If there is no ECMAScript-level default locale list, however, callers will almost always want to provide a locale list. It's then better to have a separate localeList argument rather than a property on options, so that the creation of an options object can remain optional.

Norbert



On Nov 18, 2011, at 14:17 , Nebojša Ćirić wrote:

> I think that we have agreement on being able to set global locale and to move locale list into options (anybody against?).
> 
> 
> 18. новембар 2011. 13.16, Erik Arvidsson <erik.arvidsson at gmail.com> је написао/ла:
> On Fri, Nov 18, 2011 at 12:41, Norbert Lindenberg
> <ecmascript at norbertlindenberg.com> wrote:
> > With that, the first example would become:
> >
> > var price = 300,
> >    currency = price.toLocaleString(localeList, {style: "currency", currency: "USD"});
> 
> We also talked about moving the localeList into the options and
> defaulting to the default localelist which would make it even more
> concise.
> 
> var price = 300;
> var currency = price.toLocaleString({style: "currency", currency: "USD"});
> 
> --
> erik



More information about the es-discuss mailing list