In response to both Learner and Thomas, I think those "dynamic" solutions would be great to have in later releases, so as to first support GWT 2's existing functionality, and second optimize for use cases like runtime strings changing or leaning on closure directly to improve compile times (and directly interop with other js libs that also happen to use closure, though in my experience this sadly tends not to be a long list). I've been playing with the new Intl for both NumberFormat and DateTimeFormat, and both seem somewhat lacking compared to what GWT offers - there is no option to provide your own format string as far as I can tell, only request various options. This might work for 80% or so of cases, but I can imagine things getting very frustrating for that last 20% without each project writing their own parser if GWT's i18n doesn't support it. DateTimeFormat.formatToParts looks like it could potentially be used as a primitive in building this functionality (if we wanted to forgo any JVM support) perhaps. That said, formatToParts is still not well supported yet (no Edge, no IE11, no FF ESR). -- Colin Alworth co...@colinalworth.com
On Sun, Jan 7, 2018, at 1:06 PM, Thomas Broyer wrote: > > > 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[1] or >> CellTree[2] 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()[3] 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 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/d3466879-fa8d-4ea3-840f-c57aabb171bf%40googlegroups.com[4].> > For more options, visit https://groups.google.com/d/optout. Links: 1. 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- 2. 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- 3. https://google.github.io/closure-library/api/goog.html#getMsg 4. https://groups.google.com/d/msgid/google-web-toolkit-contributors/d3466879-fa8d-4ea3-840f-c57aabb171bf%40googlegroups.com?utm_medium=email&utm_source=footer -- 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/1515473502.2510383.1227894008.2E1440DE%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
