On Thu, Mar 18, 2010 at 12:11 PM, Lex Spoon <sp...@google.com> 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, and in this case the tool could take into account locale inheritance/aliases? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
