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:









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