On Tue, May 12, 2009 at 11:12 PM, Freeland Abbott <[email protected]>wrote:
> 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. > I think it would be really unfortunate if we kept an extra permutation since one of the reasons for doing all this in the first place is to limit the number of permutations for development. Also, I think there are many other places that would need to be changed, such as all the runtime locale handling. One complication is that classes we don't control, such as user-supplied output formatters, would need to be changed as well. Otherwise, I think the approach is ok, although I am not sure doing it late like this is less work than changing the set earlier. -- John A. Tamplin Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
