i18n API implementation issues

Gillam, Richard gillam at lab126.com
Wed May 18 17:20:03 PDT 2011


My votes, for whatever they may be worth...

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

That seems appropriate to me.

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

I think you should strive to define this precisely, unless it's going to put an undue burden on some subset of implementers.  But I think you want to find a precedent and stay as close to it as possible.  You want to avoid reinventing wheels.

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:

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)?

I'm going to have to take another look at the strawman (the current version you're working from is posted somewhere, right?), but I think there's some value here and that your suggestion of using "undefined" seems reasonable.

Just the same, it'd be better if the derive() method were smart enough to know that specifying "dateType" isn't going to do anything unless it also un-defines "skeleton".  Otherwise, the developer has to remember that, or discover it the hard way.

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.

Probably better to just use the locale, unless that's going to cause an undue burden for implementers.  (From my perspective, I'm trying to implement this on top of ICU, and would prefer whatever forces me to write the least amount of code above and beyond what ICU provides.)

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

I don't really care.

As I said, for whatever it's worth...

--Rich Gillam

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

More information about the es-discuss mailing list