On Thu, Mar 4, 2010 at 2:22 PM, BobV <b...@google.com> wrote: > > The fix was the generator needed to know which locales were combined > > together so it could produce a more optimal shared solution. How would > that > > fit in here? > > Would it be sufficient if the SelectionProperty interface were to > include a getCollapsedValues() that would indicate the other values > that are equivalent to getCurrentValue()?
Yes, I believe so. > > Also, it would be nice if the matching behavior could be customized -- > for > > example, users can get runtime locales automatically just be inheriting > > CldrLocales, and they will automatically get any locales that inherit > from > > the current deferred binding property. Maybe there could be a class > > specified to do the collapsing, or maybe on the definition of the > property > > you could provide a way for code to identify default collapsing. > > That seems excessively complicated when the user will have had to > specify an <extend-property> somewhere. For example, take a look at Showcase. It has <extend-property> entries only for the main languages, and then it gets all the relevant runtime locales by simply including CldrLocales. As a more complicated example, an internal app has different translations for Latin-American Spanish from the rest of the Spanish translations, so they have es and es_419 as deferred binding properties. Then they inherit CldrLocales, and automatically get the right set of runtime locales in the es_419 permutation (es_MX, es_AR, etc but not es_ES etc). If they had to manually specify this, and alter the complete set of collapsed properties each time they added a new deferred-binding locale it would be a real hassle. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
