harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib][internationalization]Are log messages and tools usage text to be internationalized?
Date Fri, 15 Sep 2006 09:15:43 GMT
> In general, IMO it would be right to leave empty string instead of renamed
> keys. Thus in the future it will be easy to see which keys are skipped in
> the enumeration to add new messages with these ids.

+1, I think this should work.

Thanks,

2006/9/15, Ilya Okomin <ilya.okomin@gmail.com>:
> On 9/15/06, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
> >
> > Hi Ilya,
> >
> > Just to make sure. Yesterday I have added a new method to the
> > PropertyDescriptor class from the beans module. It contains two new
> > exception messages so I just took next two ids "beans.47" and
> > "beans.48". Does this fit to the new scheme? I hope you are not going
> > to renumber ids after renaming keys for console messages...
>
>
> Hello, Alexei!
>
> Of course there is no need to renumber ids, it will definitely take too much
> time and I think it's senseless.
> You can add new messages as you suggested for beans changes.
> In general, IMO it would be right to leave empty string instead of renamed
> keys. Thus in the future it will be easy to see which keys are skipped in
> the enumeration to add new messages with these ids.
>
> Regards,
> Ilya.
>
> Thanks,
> >
> > 2006/9/13, Ilya Okomin <ilya.okomin@gmail.com>:
> > > Agree, we should follow the conventions we've reached.
> > > For future updates I'll add the convention to the HARMONY-1308 comments,
> > > where the way to internationalize messages is described.
> > > As for already processed modules, I've found only few error strings and
> > > console messages in beans, auth, security, instrument and logging
> > > modules. Thus we can leave it as is now for these modules and do it
> > later in
> > > lazy way.
> > > Messages naming convention is seems to me more important for modules
> > with a
> > > huge number of messages of different types, such as x-net and rmi. These
> > > modules have not been internationalized yet.
> > >
> > > Regards,
> > > Ilya.
> > >
> > > On 9/13/06, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> > > >
> > > > I believe it could be done in lazy way...
> > > > But it defenetly should be done.
> > > >
> > > > SY, Alexey
> > > >
> > > > 2006/9/13, Oleg Khaschansky <oleg.v.khaschansky@gmail.com>:
> > > > > Hi,
> > > > >
> > > > > Are there any non-exception messages in the other modules which are
> > > > > already internationalized? I think, if there are any, they should
be
> > > > > modified to follow the new convention.
> > > > >
> > > > > --
> > > > >  Oleg
> > > > >
> > > > > On 9/12/06, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Jimmy, Jing Lv wrote:
> > > > > > > > 2. add a prefix to the String name, for an example,
> > rmi.console.1,
> > > > > > > > rmi.errormsg.2. it can be more detail.
> > > > > >
> > > > > > Ilya Okomin wrote:
> > > > > > > The way to use prefixes in the keys names to separate messages
> > of
> > > > one type
> > > > > > > from another looks to me pretty convenient
> > > > > >
> > > > > > Nice idea guys, +1 from me
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > 2006/9/11, Ilya Okomin <ilya.okomin@gmail.com>:
> > > > > > > Thanks all for useful comments!
> > > > > > >
> > > > > > > The way to use prefixes in the keys names to separate messages
> > of
> > > > one type
> > > > > > > from another looks to me pretty convenient. If there are
no
> > > > objections I
> > > > > > > would use default key names "<module>.<id>"
for exception
> > messages,
> > > > and
> > > > > > > <module>.<prefix>.<id>  for certain messages
where <prefix> is
> > "log"
> > > > or
> > > > > > > "console" (or any other key word depending on the purpose).
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ilya.
> > > > > > >
> > > > > > > On 9/11/06, Jimmy, Jing Lv <firepure@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Ilya Okomin wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > During rmi module internationalization I've faced
with loads
> > of
> > > > log
> > > > > > > > > messages
> > > > > > > > > (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi).
> > > > > > > > > Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings)
have
> > > > strings
> > > > > > > > that
> > > > > > > > > are the usage texts of any console tool.
> > > > > > > > > I think we shouldn't internationalize such messages,
however
> > I'm
> > > > not
> > > > > > > > really
> > > > > > > > > sure about that.
> > > > > > > > > If we internationalize them - we'll obtain fully
> > > > internationalized
> > > > > > > > module
> > > > > > > > > it is an advantage.
> > > > > > > > >> From the other hand - if you have to analyse
someone's log,
> > it
> > > > is
> > > > > > > > >> useful if
> > > > > > > > > the common langauge was used. Moreover, messages.propertiesfile
> > > > with
> > > > > > > > the
> > > > > > > > > list of all messages will be too huge to find
appropriate
> > > > messages for
> > > > > > > > new
> > > > > > > > > classes developed later.
> > > > > > > > > Any thoughts?
> > > > > > > > >
> > > > > > > >
> > > > > > > > IMHO, we have agree on that all console output can
be
> > > > internationalized.
> > > > > > > >
> > > > > > > > If the only problem of a too huge messages.properties
file is
> > to
> > > > find
> > > > > > > > appropriate, I guess we can:
> > > > > > > > 1. Separate the file into several smaller ones, one
for
> > console,
> > > > one for
> > > > > > > > error message, etc. Or
> > > > > > > > 2. add a prefix to the String name, for an example,
> > rmi.console.1,
> > > > > > > > rmi.errormsg.2. it can be more detail.
> > > > > > > >
> > > > > > > > In this way we can find some certain message easy.
And I
> > prefer 2.
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Best Regards!
> > > > > > > >
> > > > > > > > Jimmy, Jing Lv
> > > > > > > > China Software Development Lab, IBM
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > --
> > > > > > > Ilya Okomin
> > > > > > > Intel Middleware Products Division
> > > > > > --
> > > > > > Alexei Zakharov,
> > > > > > Intel Middleware Product Division
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey A. Petrenko
> > > > Intel Middleware Products Division
> > > >
> > > --
> > > --
> > > Ilya Okomin
> > > Intel Middleware Products Division
> > >
> > >
> >
> >
> > --
> > Alexei Zakharov,
> > Intel Middleware Product Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> --
> Ilya Okomin
> Intel Middleware Products Division
>
>


-- 
Alexei Zakharov,
Intel Middleware Product Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message