Hi Stefan,
On Tue, May 25, 2010 at 6:32 PM, Stefan Bachert wrote:
> Hi Alexandros,
>
> On 24 Mai, 17:30, Alexandros Papadakis wrote:
> >
> > Spring MVC, has a very nice way to handle this: Just put the properties
> file
> > in a specific directory
> > and everything works more or less ok..
>
> W
Hi Alexandros,
On 24 Mai, 17:30, Alexandros Papadakis wrote:
>
> Spring MVC, has a very nice way to handle this: Just put the properties file
> in a specific directory
> and everything works more or less ok..
When you want to do the same, do it with GWT. Make a service loading
your properties fi
Hi,
we do also prefetch all messages in the host page and it works pretty
well for us.
Michael
On May 24, 7:23 pm, Alexandros Papadakis wrote:
> On Mon, May 24, 2010 at 7:11 PM, Thomas Broyer wrote:
>
> > On 24 mai, 17:30, Alexandros Papadakis wrote:
> > > Regarding the i18n issue, we have th
On Mon, May 24, 2010 at 7:11 PM, Thomas Broyer wrote:
>
>
> On 24 mai, 17:30, Alexandros Papadakis wrote:
> > Regarding the i18n issue, we have the following problem: We have one
> average
> > sized
> > application which we deploy many times.
> >
> > For every deployment, labels and other i18n r
On 24 mai, 17:30, Alexandros Papadakis wrote:
> Regarding the i18n issue, we have the following problem: We have one average
> sized
> application which we deploy many times.
>
> For every deployment, labels and other i18n related information changes.
> For every installation
> we have to go th
ct, and they do in general not depend in users locale.
> >
> > > So it is perfectly OK to apply i18n on the client. And this approach
> > > is quite fast.
> >
> > > On the other hand, you don't have to use the GWT i18n mechanism at
> > > all.
> > >
fast.
>
> > On the other hand, you don't have to use the GWT i18n mechanism at
> > all.
> > And you could use the Constants-Interface and implement it by a class
> > which ask the server for values. This might be appropriate when you
> > for some reason are not abl
Hi,
conceptionelly PDF, XLS and eMails are just an other client /
presentation of your domain object/model.
The problem with (classical) web technology is, that the lack of a
clean architectural separation.
Recently I called classical web technology being a:
Real fat client living on a server us
However, your application startup will slow down.
>
> Stefan Bacherthttp://gwtworld.de
>
> On 23 Mai, 04:46, dmen wrote:
>
> > I wanted to start a discussion about this as I usually get this ugly
> > feeling when ever I take on GWT i18n . To begin with, I believe that
>
It is not so simple with server and client separation.
For example reports (PDF, XLS). You can't do them on client to the
server should be made aware of user language and presumably have the
same translational table as client does.
Other type of server-side code with i18n are e-mail messages.
GWT i18n works fine for huge projects with thousands of messages.
For our smaller projects with hundreds of messages I'm going create
adaptation for GWT of Java version of GNU gettext .
In maven build I'm panning to use http://code.google.com/p/gettext-commons/
to extract messages.
This should pre
opriate when you
for some reason are not able to supply stable translations of your
labels and titles. However, your application startup will slow down.
Stefan Bachert
http://gwtworld.de
On 23 Mai, 04:46, dmen wrote:
> I wanted to start a discussion about this as I usually get this ugly
>
I wanted to start a discussion about this as I usually get this ugly
feeling when ever I take on GWT i18n . To begin with, I believe that
internationalization is, inherently, a server side issue, so solving
it on the client is the wrong way to do it. Moreover, the way it is
done, by compiling the
13 matches
Mail list logo
