Re: [classlib]strings externalization

[Ilya Okomin <il...@gmail.com>]

On 8/31/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
>
> Ilya Okomin wrote:
> > Hi, Jimmy!
> >
> > It's great that you are interested in it!
> > Unfortunately there is no automatic externalization generation tool that
> > fits our needs. However, you can combine Eclipse externalization tool
> with
> > some manual work to get what is need. You can take a look into the
> > [classlib]strings externalization thread [1] for details. Main points
> > briefly:
> > 1. Using Eclipse externalization tool you can extract all strings from
> the
> > sources. When you process certain source file strings that used for
> > messages
> > should be externalized, others should be ignored (as a result, Eclipse
> mark
> > them with non-nls tag).
> > 2. Eclipse tool by default suggests you to use keep messages from each
> > class
> > in the separate messages.properties file, and keys in the properties
> file
> > will looks like <class_name>.<id>. We've decided to have one messages
> list
> > for each module with keys <module>.<id> (in your case <module> ==
> > instrument
> > :)). Thus at first you should change common prefix to "<module>.". Next
> > step
> > is to configure "Accessor class" field: choose the proper package for
> > Messages class and messages.properties file("org.apache.harmony
> > .<module>.msgstool").
> >
> > What is to take care of:
> > 1. Continuation of the numeration of messages. For every new source file
> > you
> > process Eclipse tool will reset enumeration, and you should manually set
> > the
> > appropriate number for messages. Also it would be better if you avoid
> > messages duplication in the list. (Pretty annoying if you have many
> > messages
> > in the module and some of them are duplicated)
> > 2. Messages formatting. If you have message located on the several
> source
> > code lines - you should concatenate them into one message string and use
> > one
> > Messages.getString(..) call. Also messages with arguments are supposed
> > to be
> > converted to strings with places for substitution by parameters being
> > arguments in Messages.getString() method. E.g. code:
> >
> > int param;
> > ...
> > NullPointerException("foo " + param + " bar");
> >
> > supposed to be formatted as
> >
> > NullPointerException(Messages.getString("<module>.1", param));
> >
> > where "<module>.1=foo {0} bar" in the resource bundle.
> >
> > I hope now the process is clear.
> > You can find examples of internationalized messages in the [sql] module.
> >
> > As for messages in native code, actually I dealt only with java code.
> > You may find something interesting for you from the "[drlvm] proposals
> for
> > VM c" thread [2].
> >
> > Regards,
> > Ilya.
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/%3cc79906b30607270353y4dfdb16bw92bc48fed76cb1c0@mail.gmail.com%3e
> >
> > [2]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/%3c23951bd90607122308i721c9c6xfcfe786f9d1e26de@mail.gmail.com%3e
> >
> >
>
> Thanks Ilya, I'll apply patch soon. I deal with Java code only this
> time, it is simple that I only find 3 strings :) I'll put them in
> messages.properties under instrument with name "instrument.1(2,3)" and
> update codes.
> Instrument also have an console output string, I suggest also put it to
> property file so it can be internationalization as well. Then there are
> 4 total.
> And strings in native code may be refactored if we have conclusion of
> native internationalization.


You are lucky, some modules have more then 50 different messages to
internationalize:)
I've already uploaded patches for several modules (e.g. auch, archive) you
can take a look for examples there.
If you've finished with instrument you can update HARMONY-1333 issue.
 You are right about console output string, it is also "a message".
One note, if there is not so many messages in your module - it would be
great to have comments with message key and it's value before
Messages.getString() call. It will be usefull to have this info right in the
source code not to spend time looking for it in the messages.propertiesfile. (
e.g. it is done in sql module)

Regards,
Ilya.

<snip>
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
> ---------------------------------------------------------------------
> 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