Re: EcmaScript i18n API proposal

2010-06-11 Thread Nebojša Ćirić 
Hi Erik,
 see my responses inline.

On Wed, Jun 9, 2010 at 8:53 PM, Erik Corry erik.co...@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:

1. We would need to agree on what goes into JSON (yet another standard?)
2. How would one use JSON data (rewrite parts of ICU or Windows i18n calls
to use JSON?)
3. 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.


 2010/6/9 Nebojša Ćirić c...@google.com:
  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 API (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.
  --
  Nebojša Ćirić
 
  i18n team,
  Google Inc.
  ___
  es-discuss mailing list
  es-discuss@mozilla.org
  https://mail.mozilla.org/listinfo/es-discuss
 
 




-- 
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript i18n API proposal

2010-06-10 Thread Nebojša Ćirić 
I'll fix that, thanks for pointing out.

Also, the doc is now moved to wiki at
http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api

If there is a way I would also mark all of the properties with read-only
attribute.

On Wed, Jun 9, 2010 at 6:17 PM, Mark S. Miller erig...@google.com wrote:

 Hi Nebojš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 Wed, Jun 9, 2010 at 6:11 AM, Nebojša Ćirić c...@google.com wrote:

 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 
 APIhttp://docs.google.com/Doc?docid=0AW406aVETP5_ZGh0dHJxNXZfMGM4azV2a2Rohl=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.

 --
 Nebojša Ćirić

 i18n team,
 Google Inc.

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




 --
 Cheers,
 --MarkM




-- 
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript i18n API proposal

2010-06-10 Thread Mark Davis ☕ 
*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:%20Re%3A%20EcmaScript%20i18n%20API%20proposalIn-Reply-To=%3CAANLkTinLzkKUOqz4RPFOUbJydqzz6P9E-8pSDbxFWrJs%40mail.gmail.com%3E
*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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

EcmaScript i18n API proposal

2010-06-09 Thread Nebojša Ćirić 
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
APIhttp://docs.google.com/Doc?docid=0AW406aVETP5_ZGh0dHJxNXZfMGM4azV2a2Rohl=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.

-- 
Nebojša Ćirić

i18n team,
Google Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript i18n API proposal

2010-06-09 Thread Mark S. Miller 
Hi Nebojš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 Wed, Jun 9, 2010 at 6:11 AM, Nebojša Ćirić c...@google.com wrote:

 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 
 APIhttp://docs.google.com/Doc?docid=0AW406aVETP5_ZGh0dHJxNXZfMGM4azV2a2Rohl=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.

 --
 Nebojša Ćirić

 i18n team,
 Google Inc.

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript i18n API proposal

2010-06-09 Thread Erik Corry 
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.

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.

How about a system where locales can be described in a JSON based
format and loaded into the running JS implementation?

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.

2010/6/9 Nebojša Ćirić c...@google.com:
 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 API (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.
 --
 Nebojša Ćirić

 i18n team,
 Google Inc.
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss