On Tue, Mar 9, 2010 at 11:29 AM, BobV <b...@google.com> wrote: > > 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. > > This sounds like an orthogonal capability in the module syntax that > involves conditionally defining new property values. Based on your > description, would you expect to write something similar to the > following in the CldrLocales.gwt.xml file? > > <extend-property name="locale" values="es_MX, es_AR"> > <when-property-is name="locale" value="es" /> > </extend-property>
The problem is that I would have to encode the relationships into the file, and therefore have to remember to update them when the locale inheritance rules are updated, plus I can't write it for arbitrary sets of locales being collapsed. For example, the way runtime locales works today is that I can just inherit CldrLocales and define the compile-time permutations I want and things just works. My app might use some text that is different in Argentina from other Latin American countries, so I might have es (European Spanish), es_419 (Latin American Spanish), and es_AR (Argentine Spanish) as deferred-bound locales, and the rest would be runtime locales. That happens automatically without having to hack the CldrLocales file to change which locales are combined together. If later I find I need a different translation for Mexico, I just add a locale value of es_MX to my module, and everything works as before. I suppose an app developer can just be made responsible for picking all the locales they want combined together, but that seems like an unnecessary burden on them to start with (check out how many there are in CldrLocales), and a maintenance nightmare as the set of locales change (which happens pretty much with every CLDR update). It seems the current way is much better, where all they do is define the locales they need compiled separately, import CLDR locales, and then they automatically get the rest of them customized as GWT gains the information about a particular sublocale. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
