oh no, i am the one who is sorry if i made it look like that,
On Sunday, April 8, 2018 at 10:39:24 AM UTC+3, Thomas Broyer wrote:
>
> 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
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
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
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
>
From: aka...@gmail.comSent: April 7, 2018 7:23 AMTo: google-web-toolkit-contributors@googlegroups.comReply to: google-web-toolkit-contributors@googlegroups.comSubject: [gwt-contrib] Re: Porting gwt-i18n module to gwt3 a ported version of the gwt-cldr importer and gwt-cldr
a ported version of the gwt-cldr importer and gwt-cldr is now available on
github
https://github.com/vegegoku/gwt-i18n-cldr
https://github.com/vegegoku/gwt-cldr-importer
On Friday, January 5, 2018 at 7:33:48 PM UTC+2, Ahmad Bawaneh wrote:
>
> Dears
> I am working on porting the *i18n* module,
Dears
here a repository where i experiment with constants generation with apt
instead of generators, i am doing this to find what problems i might face
it is not yet complete but it covers so for the most basic use of constants.
https://github.com/vegegoku/gwt-constants-apt
Thanks
On Friday,
Dears
I am trying to simplify my understanding of the i18n module, and now i
focus on the constants part since it looks to be simple to start with, here
are my findings :
Having a constants interface
1. Values will be retrieved from a properties file, if a key is missing
from the
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
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
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*
We are not using GWT I18N at all to avoid the permutations this causes but
we absolutely do separate translation *.properties from the main code.
Translations are done by a different team, following a different schedule
and may come *after* the code release (in our case even after the product
is
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
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
14 matches
Mail list logo
