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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to