To: ECMAScriptWG@ecma.ch, ECMAScriptI18N@ecma.ch cc: From: Richard Gillam/Cupertino/IBM@IBMUS Subject: I18N meeting minutes
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:
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.
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 firstname.lastname@example.org