Then how do we expect the users of gwt 3.0 to define locales in a multi module project in a way that make i18n consistence across all modules and still allow an easy migration from GWT 2.x application?
On Saturday, January 6, 2018 at 4:42:26 AM UTC+2, Colin Alworth wrote: > > I would be interested in hearing about concrete cases where one jar adds > .properties files for a class declared in a completely different jar - I > haven't seen that done in the wild before, it sounds like a bit of a > stretch to me. It might also be something that we could formally discourage > in the "new and improved i18n tool" docs. Alternatively, I've heard of > cases where the upstream jar doesn't run the processor, but just defines > the sources and lets the downstream jar run it when it provides the rest of > the impl details. > > At the risk of sounding like I'm speaking for the team that built the > original i18n module, I see it as trying to replicate > PropertyResourceBundle behavior in the JVM, without the need to have > runtime access to the classpath. I could be mistaken, but using > PropertyResourceBundle in the way you describe (loading .properties files > from a different jar) may no longer work correctly in Java 9 anyway, at > least without custom module permissions for access (somewhat akin to > running or re-running the processor on the downstream project)? Might be > wrong on that. Reusing that .properties format for localized files and > BundleName_locale.properties file name format seems like an express design > goal to me, no matter what other changes happen along the way. > > On Friday, January 5, 2018 at 11:33:48 AM UTC-6, 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/ac2013e7-a9d1-471c-89f8-31c42fb77011%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
