On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
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.
Tim, do you mean, that Exceptions without any messages supposed to be
initialized with some corresponding message describing the problem? I
thought only already existing in modules messages are to be considered. Just
want to dispel doubts.
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.
Yep, I've chosen the same way to do.
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]
--
--
Ilya Okomin
Intel Middleware Products Division
