harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Okomin" <ilya.oko...@gmail.com>
Subject Re: [classlib][internationalization]Are log messages and tools usage text to be internationalized?
Date Fri, 15 Sep 2006 08:54:11 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message