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/[EMAIL PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
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.
<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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
