John---
Attached is a proposal---it's missing tests, so it's just a proposal
here---for that default locale issue we were looking at.  It's slightly
sideways from your suggestion: instead of not using "default" at all, this
keeps it in play (figuring that various tools, including our own generators,
expect "default" to be valid and work, always, as a safety), but instead
associates it to a given "real" local as specified with a configuration
property.

Naively (which this patch is), that does mean generating an "extra"
permutation (one for "default" even though it's the same as some other real
locale); it should be possible to skip doing the _real_ locale, retaining
default, but I haven't gotten to that yet... and the shortcut might be
invalid if you had, say, both fr and fr_CA available.  So this seemed a
useful partial of causing default to behave more completely[1] and fixing
our bug.

I also, as a proof, I've changed the i18n sample to default to French.

Take a look and let me know; assuming you like the basic idea, I'll add some
tests and send the real thing tomorrow.


[1] For others unaware of default's problems, it is the locale associated
with, for example, asking for a locale that isn't available... in my tests,
I asked for Japanese (jp) of a sample localized for English (en) and French
(fr, default).  But "default" is really a non-locale, so it's missing things
like plurality, currency, etc.... "$" is a pretty lousy generic currency
symbol, as are all the other possibilities.

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Attachment: [email protected]
Description: Binary data

Reply via email to