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]strings externalization
Date Thu, 27 Jul 2006 12:50:01 GMT
On 7/27/06, Tim Ellison <t.p.ellison@gmail.com> 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/%3cc79906b30607100414j7e135b50tc4d725c0df740673@mail.gmail.com%3e
> >
> >
>
>
> ---------------------------------------------------------------------
> 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