On Thu, Mar 18, 2010 at 12:20 PM, John Tamplin <[email protected]> wrote:
> On Thu, Mar 18, 2010 at 12:11 PM, Lex Spoon <[email protected]> wrote: > >> Yes, that's what I was thinking for complex cases. For simple cases, >> can't users already specify "en" and get a permutation with all the >> Englishes combined? >> >> Perhaps I misunderstand, though. Is the plan to stop using "en" and >> switch to having people use "en_*" to collapse down the Englishes? >> > > Right now, people who use runtime locales for the most part they just list > the compile-time locales they want translations for and inherit CldrLocales. > If we add new locales, such as recently, they don't have to change anything > and they automatically get the localized date/time/number formats and > currency names for each runtime locale. > > That is what I have been pushing to have a solution for in soft > permutations, rather than requiring them to manually create the collapse > lists is a problem. Having to run some pre-compile tool is problematic, > since how do you tell Eclipse, for example, what to run and when? > > Granted, runtime locales aren't going to be ported to soft permutations > immediately, but it still shouldn't be something that is going to make life > harder for our users when we do it. I thought the conclusion of the > discussion we had about that was to allow a module to specify a class that > could synthesize module entries It sounds like the design isn't so nailed down after all for how runtime locales will work with soft permutations. Let's please talk this over in a higher-bandwidth forum. I thought I had mentioned that developing what is essentially a macro system is possible but will take some substantial effort. Perhaps it's the thing to do, but it increases the scope of what module files support. If we don't need it, this is a place we can save a lot of effort. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
