Ilya Okomin wrote:
Hi falks!
I would like to open discussion about the way to extract messages for
internationalization from the source files (as the continuation of the
[classlib]internationalization thread [1]).
The task is to scan modules source files, find exception messages,
extract
them into the resource bundle and replace these messages in the source
files with corresponding Messages.getString() call by key parameter
from the
resource bundle.
I see three ways to solve this task:
1) Do it manually - the less attractive because of the huge amount of
manual
work.
2) Use Eclipse externalization tool. This tool provide us a
possibility to
scan source files and to check strings you would like to externalize.
Sounds
reasonable except several issues:
- At first, there is a manual work to choose from the source files
only messages related to exceptions throwing and avoid duplication of
messages at list in one class file.(however, this work is much more
easier
than one mentioned at 1) point:))
- Eclipse tool creates resource bundle with messages and Messages
class to get access to this resources in every package. Also this tool
suggests to use <classname>.id as the key of the message. In our
previous
discussion [1] it was decided to use <modulename>.id as the key and
keep all
messages in one resource file per module. Good news: during processing
source file with Eclipse tool we can set the same resource file for all
source files from the module and every time set the prefix of key
names to
the module name, also our Messages class implementation can be used
after
adding corresponding import statement into a source. Bad news:
following
this way of processing sources one can see that there is no tracking
system
for key indices numeration, in case of mistakes there can be generated
different messages with the same keys!!
- And at last, Eclipse tool processes only separated strings.
And according to the discussion [1] these messages with arguments
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 have an optitmistic thought that there are not so many messages with
parameters to process them manually after the rest of work with just
strings
is done.
3)Write own parser that will do all implement tasks automatic. In my
opinion
it's quite a non-trivial task, only if there is no tools that resolves
similar tasks.
The 2) approach seems to me more reasonable, despite some manual work.
Parser will help us to easily update bundles and sources after future
changes, but it will be not so easy to implement it.
Any thoughts on this topic?
Tim, if I'm not mistaken you dealt with strings externalization for SQL
module, it would be interesting to hear anything about the way you'd
chosen.
I did a combination of (1) and (2) as you describe above.
I also found that the Eclipse externalization tool was inadequate in a
number of areas, including creating duplicate keys and not dealing with
parameterized messages properly -- so I had to go and fix up the code
manually.
The other reason we will need some manual intervention is that there is
plenty of code that throws exceptions without any message describing the
problem, and of course the tooling won't help there.
So once we have the basic framework in place for the message handling I
think it will require a large manual effort to get all the strings that
we want externalized properly. Luckily it is not technically complex
work and it is a task that we can easily do in parallel across the modules.
Regards,
Tim
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
