I didn't mean to be dismissive of your work (sorry if that might have sounded like this); on the contrary this is valuable work, but IMO more as an "experimentation" exploring what can be done than a definitive answer to how is *should* be done now.
On Saturday, April 7, 2018 at 8:39:32 PM UTC+2, Ahmad Bawaneh wrote: > > I also one of those who replaced gwt-i18n with my own implementation which > was a simple dictionary like, that loads the labels and messages at > runtime, but in my case i didnt need more than plain simple text > translation without parameters or anything else. > > with that said, one of the goals of porting gwt 2 modules is to provide a > smooth transition for applications that uses gwt into gwt 3.0, this does > not mean we cant introduce something new or implement things differently, > but we can have both, while we are porting the old module and ensure a > smooth transition, we give ourselves a better chance and freedom to > brainstorm, introduce and discuss new things. > > while working on porting i18n module i am trying to break it into smaller > modules that are more specific to one thing, so : > 1- i started by extracting the i18n module from the monolith gwt code, and > make sure the test cases works. > 2- i have draft implementation of an APT based constants generator > https://github.com/vegegoku/gwt-constants-apt > For example, here, you pass the locales as a constant on the annotation, which is *not* a “non evolutionary porting” then. This implies that when/if you want to add a new locale, you need to go through all your constants interfaces to not only add properties files (see below about that too) but also add the locale to the annotation. I wonder if we couldn't instead pass an option to the annotation processor (we could also have the processor load the properties files from the processor path; in Gradle this would mean that changing a properties file would trigger a recompile; unfortunately this is impractical at best in Maven). An alternative would be a generator that's not an annotation processor (no idea how you'd call it; that idea maybe not worth pursuing as that could be too cumbersome for users; unless maybe the generator generates intermediate Java source that's only processed by the annotation processor later and never actually used at runtime; the goal only being that the input to javac –maven-compiler-plugin or Gradle JavaCompile task– is only made of Java source files, for more accurate incremental builds –i.e. correctly trigger a recompile when needed). Wrt properties files, current GWT 2.x implementation will look for properties files for the superinterfaces too up to Localizable; which provides a way to centralize the values across the entire application. When adding a new locale, you could then give a single properties file to the translator, and have a single new properties file to add to your application (and not one per constants interfaces; but with your proposed implementation, you'd still have to go through all of them to add the locale to the annotation). Ideally, we should also plan our annotation processors so they work great with Gradle's experimental incremental compilation: https://docs.gradle.org/release-candidate/userguide/java_plugin.html#sec:incremental_annotation_processing 3- extracted CLDR into its own module with no JSNI and JSO, the generator > is also moved out of the gwt tools into its own module and now works with > gradle instead of ant. > > and i am pretty sure there are many gwt i18n users who will appreciate > this non evolutionary porting, but also i believe this will give us a > better ground when we start introducing new things, and for such a large > module will help us with coordination and get more involved. > I agree that we should aim for maximum backwards compatibility, but there *will* be breaking changes anyway (if only to replace GWT.create() with calls to a –generated– static factory). I'll try to setup a document today with what I have in mind so we can discuss. > > Thanks > > On Saturday, April 7, 2018 at 8:46:28 PM UTC+3, Thomas Broyer wrote: >> >> >> >> On Saturday, April 7, 2018 at 3:03:39 PM UTC+2, Learner Evermore wrote: >>> >>> 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. >>> >> >> I 100% agree (as I said earlier in this thread) that we need to >> critically reevaluate and rethink how we do i18n. One thing is that we need >> to evaluate messages and constants separately from >> formatting/collation/etc. The latter could use generation from CLDR (like >> in GWT 2), or possibly delegate to the browser's native Intl ( >> https://caniuse.com/#feat=internationalization), or even possibly >> support both (with minimal to no change to the code). >> IFF we can get something that allows for dynamically switching locale >> without reloading, that would be even better (though this has –probably, >> maybe you could tell us more about how you did it– huge impacts in how you >> architecture your application) >> >> One thing appears quite clear to me though, that in terms of application >> architecture, everything should be "injected" into the components et al. >> I.e. in your application, you define your messages, etc. and most >> importantly which locales you're going to support, this would then generate >> appropriate code to handle it, and you pass the required instances >> (DateTimeFormat or whatever) down to the components coming from libraries. >> >> I believe we should brainstorm rather than rush into implementations, or >> we're going to simply copy what GWT 2 is already doing. We should aim for >> maximum backwards compatibility, but we have the opportunity of doing >> things better and introduce a few breaking changes, and we should seize it! >> > -- 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/29b158ea-f8b4-4573-9eb4-a6d44e4acc7e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
