Re: [gwt-contrib] Re: Porting gwt-i18n module to gwt3

[Learner Evermore]

I think I18N is important. However, we never liked or used the GWT 2.x style of it because it requires dev time knowledge of locales and multiplies permutations (compile time). It was also inflexible another way - e.g. if a user wants to switch or update the language the code is reloaded as well and the state lost. Instead we load localizations separately from the main code (and have the ability to automaticall, at runtime, merge it with the code, should we wish to do so).  A serious GWT must have a serious I18N system, *not* like GWT 2.x. Now, we still need to address porting of existing code - if there remains a desire for porting today. We can make that easier. However, since some work will be involved anyway, the compatibility system does not have to do it the GWT 2.x way, just needs to be more-or-less compatible with it from the coding perspective. Learner Evermore From: aka...@gmail.com Sent: April 7, 2018 7:23 AM To: google-web-toolkit-contributors@googlegroups.com Reply to: google-web-toolkit-contributors@googlegroups.com Subject: [gwt-contrib] Re: Porting gwt-i18n module to gwt3 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. 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. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/nku9meaf9l10kv6jq4dcn4mu.1523106211795%40gmail.com. For more options, visit https://groups.google.com/d/optout.