EcmaScript i18n API proposal
a,
I notice in your informal specification notation
- //* The base language code (typically a ISO-639 language code).
- // @type {string}
- Locale.language
which I assume means that instances of Locale have a "language" property. However, this notation would more naturally suggest that "language" is a property on the "Locale" constructor. We currently do not have any established compact notation for saying what you need to say here clearly. Unless anyone has a better suggestion, I suggest
aLocale.language
I've seen that used informally among Smalltalk programmers and it seems to work well.
On the face of it this proposal introduces a huge new area of incompatibilities between engines in terms of both which locales are supported and the details of the locales. The example (German phonebook locale) is suitably obscure as to illustrate the hopelessness of expecting JS engines to contain all thinkable locales.
Unless anyone has a better suggestion, I suggest aLocale.language
I've seen that used informally among Smalltalk programmers and it seems to work well.
And similarly amongst Racket (formerly PLT Scheme) programmers, except we prefer to use hyphens and all-lower-case as opposed to camel-case.
Shriram
I'll fix that, thanks for pointing out.
Also, the doc is now moved to wiki at strawman:i18n_api
If there is a way I would also mark all of the properties with read-only attribute.
On Thu, Jun 10, 2010 at 05:05, Nebojša Ćirić <cira at google.com> wrote:
I'll fix that, thanks for pointing out.
Also, the doc is now moved to wiki at strawman:i18n_api
If there is a way I would also mark all of the properties with read-only attribute.
In ES5 you can do read only properties by setting the [[Writable]] internal property to false.
Re the following message: * * It is clearly expected that the number of locales available on any particular device may be limited; a smartphone, for example, might have very few installed, or have limited services for those it does have installed. With the locale model, implementations are expected to use "the best match". That is, for a given service (like collation) if there is no support for German phonebook, then it would fallback to German; if there is no support for German then it will fall back to some default locale, such as English. The features of a locale are best thought of as requests, to be used wherever possible.
That being said, you'd be surprised at how many implementations could easily support the example German phonebook through underlying OS or library services, since it has been a standard option on Windows for quite a while (locale 0x10407 = German with phonebook sort), and in ICU -- thus in the Mac OS, on Google servers, etc.
Mark * * ===== * * * * Erik Corry erik.corry at gmail.com <es-discuss%40mozilla.org?Subject=Re: Re%3A EcmaScript i18n API proposal&In-Reply-To=<AANLkTinLzkKUOqz4RPFOUbJydqzz6P9E-8pSDbxFWrJs%40mail.gmail.com>> Wed Jun 9 11:53:14 PDT 2010
- Previous message: EcmaScript i18n API proposal <011388.html>
- Messages sorted by: [ date ] <date.html#11384> [ thread ]<thread.html#11384> [ subject ] <subject.html#11384> [ author ] <author.html#11384>
On the face of it this proposal introduces a huge new area of incompatibilities between engines in terms of both which locales are supported and the details of the locales. The example (German phonebook locale) is suitably obscure as to illustrate the hopelessness of expecting JS engines to contain all thinkable locales.
see my responses inline.
On Wed, Jun 9, 2010 at 8:53 PM, Erik Corry <erik.corry at gmail.com> wrote:
On the face of it this proposal introduces a huge new area of incompatibilities between engines in terms of both which locales are supported and the details of the locales. The example (German phonebook locale) is suitably obscure as to illustrate the hopelessness of expecting JS engines to contain all thinkable locales.
I don't think one can expect the same set of locales across all JS engines. If locale is not supported we should fall back to less specific one, with a warning.
You are correct that there would be problems with compatibility across i18n engines/libraries. ICU and Windows for example cover a lot of same locales, but I think they name them in a different way. So an JS engine implementation for ICU would differ from Windows or libc implementation (when I say Windows implementation I mean using Windows calls to collate, format... instead of a 3rd party library).
From the proposal "The biggest problem is the size and complexity of data needed for collation process". Given that this data is so huge, requiring all JS engines to include it for all locales ever invented doesn't sound good.
I think it's more the combination of algorithm complexity and data size that prevents current implementation (closure, dojo) to offer collation. Also, most of the locales have fairly small data set needed for the collation (couple of kilobytes). The biggest tables are for CJK, but they can be pruned down (with loss of features).
Android for example uses ICU in pruned down form - it supports only subset of all ICU locales, and I think that's a usual approach for other features in smartphone industry (including fonts).
Most of the browsers already have full access to the collation data (IE through Windows API, Chrome through ICU...), so they wouldn't grow in size, if JS engine were to use that data.
How about a system where locales can be described in a JSON based
format and loaded into the running JS implementation?
There are some projects underway that would host/expose CLDR data as JSON objects, but I am afraid that would bring more problems to the proposal:
- We would need to agree on what goes into JSON (yet another standard?)
- How would one use JSON data (rewrite parts of ICU or Windows i18n calls to use JSON?)
- Where to host JSON data, what if the user is offline?
A positive thing about the proposal: It doesn't, if I have understood it correctly, have a concept of a context-global locale setting. No global state? I like this.
Yes, it doesn't have global locale. You are free to create as many locales per, say web page, and use them to sort, format and parse.
We would like to propose adding i18n API to the EcmaScript standard (either as standard library or part of the language).
Our current proposal is at EcmaScript i18n APIdocs.google.com/Doc?docid=0AW406aVETP5_ZGh0dHJxNXZfMGM4azV2a2Ro&hl=en (open to edits). We will migrate the document to the proper strawman wiki page as soon as we get access to it.
We feel that our current proposal represents the minimum set of objects and methods needed, but we could certainly extend it to cover number/currency formatting/parsing and possibly calendar support. Our main goal was to start with minimal proposal and get early feedback from the community.
Please leave feedback to the proposed API either inside of the document or post back to the mailing list.