On Sunday, January 7, 2018 at 7:00:45 PM UTC+1, Thomas Broyer wrote: > > > On Friday, January 5, 2018 at 6:33:48 PM UTC+1, 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. >> > > Thanks for taking this initiative; i18n support indeed is a must-have. > I however think we need to critically reevaluate our current design > (particularly in light of the new JS Intl APIs that already have wide > browser support: > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl > ). > Constants, ConstantsWithLookup, Messages, and CustomDateTimeFormat however > are likely to stay similar though (and have their implementation rely on > those new APIs). > > >> 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? >> > > I think anything that supports localization should expose ways to replace > the constants or messages being used, like SimplePager > <http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/cellview/client/SimplePager.html#SimplePager-com.google.gwt.user.cellview.client.SimplePager.TextLocation-com.google.gwt.user.cellview.client.SimplePager.Resources-boolean-int-boolean-com.google.gwt.user.cellview.client.SimplePager.ImageButtonsConstants-> > > or CellTree > <http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/cellview/client/CellTree.html#CellTree-com.google.gwt.view.client.TreeViewModel-T-com.google.gwt.user.cellview.client.CellTree.Resources-com.google.gwt.user.cellview.client.CellTree.CellTreeMessages-> > > do, or possibly commit to providing localization for as many locales as > possible. > That way, applications can pass their own messages. > > An alternative is to re-run the annotation processor in the downstream > module for the upstream class (call javac passing the interface name rather > than –or in addition to– compiling files) so it has access to your new > properties files; and then rely on classpath shadowing to use your version > rather than the original. This doesn't fit well with Java 9 JPMS as far as > I can tell, but it at least provides an alternative until APIs change to > allow "injecting" your own messages as suggested above. >
I completely forgot that we could also possibly have Messages and Constants compile down to Closure Library's goog.getMsg() <https://google.github.io/closure-library/api/goog.html#getMsg> for later processing by the Closure Compiler. This obviously means that it wouldn't work with GWT 2 though, and tightly bounds us to the Closure Compiler (not just for goog.module/goog.require module loading), but the upside is that the translations are provided at the very final Closure Compiler stage (but then, this raises a new question: how libraries would easily contribute their translations to applications?) -- 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/d3466879-fa8d-4ea3-840f-c57aabb171bf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
