i18n API implementation issues

Nebojša Ćirić cira at google.com
Wed May 18 14:04:01 PDT 2011

Hi all,
 Jungshik and I were working on v8 implementation and we have almost
everything done (number formatting is not done, and some parts of
collation). There are some issues I would like to discuss (I made an update
to the strawman):

1. For LocaleInfo I would like to include construction with plain string:
new LocaleInfo(*"de"*) vs more verbose new LocaleInfo(*{'languageID': 'de'}*

One would be able to construct LocaleInfo like this:
LocaleInfo(); - default
LocaleInfo({}); - default
LocaleInfo({'languageID': 'sr', 'regionID': 'RU'); - and all variations
(missing regionID, missing languageID).

2. Language matching - how detailed should we go in specifying language
matching process?

I assume each platform has its own way of finding the best match for a user
provided language ID. Should we just leave it at that?

I would like to propose one requirement:

If user specifies "de-AT-u-co-phonebk" and language matcher produces "de-DE"
as closest match, we should keep the extension and produce final

3. Derive methods were introduced to simplify creation of objects by
tweaking current settings. It works well when you override existing setting
or when you add new one. It's not so great when you want to remove a
setting. For example:

var dtf = new DateTimeFormat({'skeleton': 'MMMy'});

// Skeleton has higher priority than timeType and dateType fields so we have
to remove it in order for dateType override to have any effect.
var derivedDtf = dtf.*derive*({'skeleton': undefined, 'dateType': 'short');

The example is somewhat forced since user would probably just create new DTF
in this case instead of deriving, but I wanted to show the problem with
reseting the setting.

The question is - do we keep derive methods? If so, do we care about this
case/my solution (since user has other ways to create the object)?

4. Should we rename LocaleInfo.*collator*()/*numberFormat*()/*dateTimeFormat
*() into LocaleInfo.*createCollator*()...? It makes it clear we are creating
new object.

5. I think that *calendar* settings for DateTimeFormat doesn't bring much
value and makes implementation more complex. Overriding default calendar is
rare operation, and can be easily done with -u-ca extension - one just needs
to create new locale.

6. I would rename *dateSkeleton* into *skeleton* in DateTimeFormat settings.

Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110518/d86d8b2b/attachment.html>

More information about the es-discuss mailing list