success

fail

		Jun AUG Jan 15 1999 2000 2002
15 captures 02 Oct 1999 - 18 Sep 2003

About this capture

COLLECTED BY

Organization: Alexa Crawls

Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.

Collection: Alexa Crawl AUG

Crawl AUG from Alexa Internet. This data is currently not publicly accessible.

TIMESTAMPS

To:   ECMAScriptWG@ecma.ch, ECMAScriptI18N@ecma.ch
cc:
From: Richard Gillam/Cupertino/IBM@IBMUS
Subject:  I18N meeting minutes

Hi everyone--

The ECMAScript internationalization subcommittee met today from 10 to 4:30, and I wanted to send out a note recapping what we discussed and decided. I'll put out a new copy of the draft proposal sometime in the next couple days, and I'll send it to both mailing lists, as well as circulating it around here at IBM for feedback.

The one piece of administrative news is that I'm now officially the chair of this subcommittee (as we all know, that doesn't mean you have the respect of your peers so much as it means no one else wants the job). :-)

We wound up settling on a two-tier approach. There would be a separate internationalization library, resting on an as-yet-undetermined packaging framework. The bulk of the support in the language would be in this library, which would be "kind of optional". By "kind of optional," I mean that a conforming ECMAScript implementation could omit it, although this is strongly discouraged except for very small things like embedded applications. A program requiring this librar would issue some kind of "import" directive at the beginning of execution and dump out immediately if the library weren't available.

The idea here is that implementations that are very concerned about the size of the runtime could bag internationalization. This would generally apply only to code that is intended only for a specific environment in the first place and isn't intended to be portable. For more general code, the application should be able to depend on the internationalization library being there, but keeping it separate helps from an implementation standpoint, allows the environment to wait to pull it in until it's actually needed, and so forth. We proceeded on the assumption that the i18n library would be there some 90% or more of the time.

We spent the rest of the meeting focusing on which i18n APIs are important enough to include in the core language (and guarantee they're there ALL the time) and which should be in the separate i18n library or dropped altogether. We also focused on some other proposed changes to the existing draft of the standard that I had proposed to track Unicode better or to clarify things. We didn't really focus too much on what exactly would be in the separate i18n library, or how those APIs would look. We discussed this some, but didn't nail down any conclusions. The idea right now is to focus on the changes we think should be made to the core language and then when that settles down go back and start deciding how the rest of the i18n support should look.

That left us with very little in the core language:

FORMATTING

We agreed to add a toLocaleString() function to the Object prototype. This function would take one parameter, called "locale". The default implementation on Object would ignore the locale parameter and just call toString().

Number would override toLocaleString() to provide "locale sensitive" number formatting. If the i18n library was present, it would vector through to a more full-featured API in the i18n library. This function would interpret the locale parameter as a locale object (which would be defined in the i18n library, not in the core) and behave accordingly (Null and Undefined would both be treated as specifying the current system default locale). If the i18n library wasn't present, Number.toLocaleString() would ignore the locale parameter and either format the number properly for the system default locale (with the specifics being implementation-dependent) or just call toString(), depending on the environment and what was available.

Array would override toLocaleString() to call toLocaleString() on the elements in the array, passing through the locale parameter.

Date's existing toLocaleString() would now be an override of Object's toLocaleString() and would take a locale parameter (this still backward compatible, since you can leave out that parameter and everything still works). It'd work basically the same way Number.toLocaleString() works .

[There was some discussion about whether Date.toLocaleString() should have another parameter that lets you say whether you want to see the date, the time, or both, but since Date.toString() doesn't have that now (and it' s not strinctly an i18n issue) we didn't do this. It should probably be added to both functions.] In general, options to let the user control the appearance of the output (e.g., the precision of a formatted number or the long or short form of a formatted date) are implemented only in the i18n library.

There was some related discussion about whether there should be some kind of getListSeparator() function somewhere that user-defined formatting functions could use to get locale-sensitive formatting in more cases. We left this open without decided whether this was a good idea, what else fit into this category, or where it would go.

PARSING

Parsing is still an open issue (or an open wound). I think we all agreed that localized date parsing should either be in the i18n library or left out altogether. Localized number parsing we're still talking about. Graceful fallback isn't an acceptable solution here as it is in formatting, and we're not sure what to do instead. This needs more work.

STRING COMPARISON

We decided to move locale-specific string comparison into the separate i18n library.

MESSAGE FORMATTING

We decided to have a message formatting API in the separate i18n library, but not in the core language (and I think we still have some people who are skeptical about having this feature at all).

CASE MAPPING

We decided to have String.toUpperCase() and String.toLowerCase() take an optional locale parameter and do fully language-specific case mapping where possible. When not possible, falling back on just the mappings in the Unicode 2.1 character database would be acceptable. We'll do a String.toTitleCase() in the i18n library.

UNICODE NORMALIZATION

We agreed to require that all text, by the time a running ECMAScript program sees it, is in Unicode Normalized Form C, but not to say any more about who does that. We decided not to provide a programmatic way of doing Unicode normalization in the core language; it's still an open issue whether to have it in the i18n library.

UNICODE VERSION

We decided to require Unicode 2.1 or later (so programmers can always depend on the Euro symbol being there). We're still trying to figure out appropriate language to allow implementers the freedom to adopt future Unicode versions without breaking existing programs (there's a particular problem when errors in things like character category assignments are corrected).

REGEXP SUPPORT

We added clarifiying language to the section on regular expressions indicating that regexp support is not intended to be used for processing natural language. We also agreed to follow the Perl syntax (which is still in flux) with regard to how a user specifies a Unicode character category (e.g., you can't use "[a-zA-Z]" to mean "all letters" in a Unicode-based environment).

We're still thinking about just how the i18n library would be organized and which features (other than the ones mentioned above) should be in it. Much of the discussion centers around whether you just have a Locale object which has all the protocol for localizable behavior hanging off of it, or whether there's some other way to divide things up (one option is to have a lightweight LocaleID class and a separate Locale class that contains behaviors [analogous to Locale and ResourceBundle in Java?]). We've tabled most discussion on the external i18n library until the i18n features in the core language settle down a bit. Right now, the plan is to start worrying about that after we achieve (or near) closure on the rest of this stuff in January.

And that's about it. For now, unless we get stuck on something, we're planning to do the rest of the work on this first proposal via email and present something in January. I plan on circulating the latest draft of that proposal once I finish it, which should be in the next few days.

If anyone on the i18n subcommittee has corrections or clarifications, please go to it. Otherwise, I look forward to hearing how things go tomorrow.

Thanks a lot...

--Rich Gillam
  Advisory Software Engineer, Text & International
  Center for Java Technology, Silicon Valley
  IBM Network Computing Software Division
  (408) 777-5864
  rgillam@us.ibm.com