a ported version of the gwt-cldr importer and gwt-cldr is now available on github
https://github.com/vegegoku/gwt-i18n-cldr https://github.com/vegegoku/gwt-cldr-importer On Friday, January 5, 2018 at 7:33:48 PM UTC+2, Ahmad Bawaneh wrote: > > Dears > I am working on porting the *i18n* module, so far all i did is extract > the module and the tests into and external repository and make the tests > pass, not real change to the code have been yet. but the *i18n* module is > an important module and is being used by so many gwt application so porting > this one should be taken with care, this why i am opining this discussion > so that i can hear and share idea's. > > i would like to start this discussion by sharing some of my thoughts, > which are limited to my knowledge of the gwt *i18n*, and i would love to > get corrections and feedback to what ever wrong or good thinking i have. > > so first in a gwt 2.x application using *i18n* with generators assumes > that the set of locales available is known during the code generation, for > example if you an application that has a module lets call it module *A* > that define a messages interface (*MessagesA*) and defines the locales to > be `*en*`, `*fr*` for example, then once the application is compiled, the > generator should produce *MessagesA* class for each locale and we end up > with *MessagesA_en* and *MessagesA_fr* having that we provide properties > files for both. > > now assume we add a new module to our application module *B* and B > defines another messages interface *MessagesB* and extends the locale > property to add a third locale `*it*` and provide properties files for > *MessagesB > en,fr and it* and also provide a properties file for* MessagesA it*, then > when we compile we will end up with *MessagesA_en*, *MessagesA_fr*, and > *MessagesA_it*, *MessagesB_en*, *MessagesB_fr*, and *MessagesB_it*. > > with this i could extends the application messages by adding a new module > thanks to the Property oracle that provide information about all defined > and extended locales. > > now in the APT world with multi modules things are different, the > processors does not rum for all modules as one unit instead the processor > will run for a single module and will have knowledge limited to that > module, so module *A* processor wont know about locales defined in > module *B*, and module *B* processor wont know about locale values > provided by module *A*, so and expected result that i will end up with > *MessagesA_en*, *MessagesA_fr* for module *A* and *MessagesB_it* for > module *B*. > > what do you think? > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ab91963d-dc97-40eb-a8f0-fa51bfd32495%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
