i18n API implementation issues

Allen Wirfs-Brock allen at wirfs-brock.com
Wed May 18 15:19:57 PDT 2011

On May 18, 2011, at 2:04 PM, Nebojša Ćirić wrote:

> 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('sr');
> LocaleInfo({}); - default
> LocaleInfo({'languageID': 'sr', 'regionID': 'RU'); - and all variations (missing regionID, missing languageID).

you don't need quotes around the property names in your literal objects:
  LocaleInfo({languageID: 'sr', regionID: 'RU'); 

You could support all of the above, it's just a matter of some internal logic.  You really have tree alternative for the argument:
    a string
    an object that will be treated as a possibly empty set of option properties

> 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 "de-DE-u-co-phonebk".

Precise specification is best for interoperability.  Specify as much as you possibly can. 

> 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.

Specify undefined as the value seems fine as long as undefined as a option property value always means the same as that property being absent.  Alternatively, you could accept an optional second argument to derive that is an array of property names to delete.  Does this really occur enough to bother with any of this.  If this scenario is rare why not just not support this style of derivation.  BTW, contrary to a literal interpretation of actual language you use above, I assume that new DTF(options) and dtf.derive(options) both create a new dtf object.

> 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)?
If the same thing can be accomplished other ways and it isn't a common usage case then I recommend dropping it.

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

The methods on the LocaleInfo constructor or are they really LocaleInfo.prototype methods.  In other words are the results derived from a specific LocaleInfo instance or is the result some sort of global value that is independent of the instances. If the latter, why are they associated with the LocaleInfo constructor?

> 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ć
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110518/22d69e5a/attachment.html>

More information about the es-discuss mailing list