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.

Reply via email to