You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/05/31 11:32:40 UTC
Re: [classlib] internationalization
Mikhail Loenko wrote:
> 2006/5/25, Tim Ellison <t....@gmail.com>:
>> Mikhail Loenko wrote:
>> > We also agreed to put only internationalized messages and
>> > to have a single catalog by module.
>>
>> Yep, that's a good task for somebody who is looking for a simple way to
>> contribute to Harmony's classlibs.
>>
>> If anyone wants to volunteer then go for it -- I can help with guidance
>> if required.
>>
>> > Is there any way to meet all the agreements without rewriting the
>> > internationalization framework?
>>
>> I don't think we need to change the mechanism we use to get message
>> strings from resource catalogs, just split the single catalog up across
>> the modules.
>
> So we are splitting messages across the modules and than unite them back
> at build time, correct?
Sorry for causing confusion, I was being too brief.
I meant that the mechanism we currently have in LUNI (i.e. a resource
file of externalized strings and a helper class like Msg to load the
string and format it etc.) can be duplicated in each module that has
externalized strings e.g. for exception messages. Of course, each
module would only have its own messages.
In this case the code is quite trivial so I don't see a big problem with
duplication. At runtime, each module is a self-contained JAR with it's
o.a.h.<foo>.internal.Msg and string catalog in the JAR file.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [classlib] internationalization
Posted by Anton Avtamonov <an...@gmail.com>.
On 5/31/06, Tim Ellison <t....@gmail.com> wrote:
> Yep, we discussed that a while ago.
>
> IIRC there was some debate about how the message keys should look.
> Today we have short strings (e.g. "K1234") and there was a proposal to
> make that <module>.<id> (e.g. "beans.42"). I recall some objections to
> that proposal but cannot recreate them right now.
Yes. I proposed to have self-documenting key names.
Because when code produces some exception, for instance, I would
prefer to see something like
throw new IOException(I18N.getMessage("wrongFileFormatMsg"))
rahter than
throw new IOException(I18N.getMessage("K1234")) :-).
With my proposal it is very easy to understand the idea of the coded
message and its intention.
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [classlib] internationalization
Posted by Tim Ellison <t....@gmail.com>.
Yep, we discussed that a while ago.
IIRC there was some debate about how the message keys should look.
Today we have short strings (e.g. "K1234") and there was a proposal to
make that <module>.<id> (e.g. "beans.42"). I recall some objections to
that proposal but cannot recreate them right now.
We didn't go on to discuss the Eclipse technique of using a Message type
with fields for the messages.
Regards,
Tim
Alex Blewitt wrote:
> Not sure if it's particularly relevant, but the piece on Eclipse
> performance bloopers is a good read:
>
> http://www.eclipse.org/eclipse/development/performance/bloopers.html
>
> Specifically, it mentions items to do with using string keys, the
> dangers of using substring() and why they created their own binding
> from messages-to-keys framework instead of using the standard Java
> property list.
>
> Alex.
>
> On 31/05/06, Tim Ellison <t....@gmail.com> wrote:
>> I meant that the mechanism we currently have in LUNI (i.e. a resource
>> file of externalized strings and a helper class like Msg to load the
>> string and format it etc.) can be duplicated in each module that has
>> externalized strings e.g. for exception messages. Of course, each
>> module would only have its own messages.
>
> ---------------------------------------------------------------------
> 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
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [classlib] internationalization
Posted by Alex Blewitt <al...@gmail.com>.
Not sure if it's particularly relevant, but the piece on Eclipse
performance bloopers is a good read:
http://www.eclipse.org/eclipse/development/performance/bloopers.html
Specifically, it mentions items to do with using string keys, the
dangers of using substring() and why they created their own binding
from messages-to-keys framework instead of using the standard Java
property list.
Alex.
On 31/05/06, Tim Ellison <t....@gmail.com> wrote:
> I meant that the mechanism we currently have in LUNI (i.e. a resource
> file of externalized strings and a helper class like Msg to load the
> string and format it etc.) can be duplicated in each module that has
> externalized strings e.g. for exception messages. Of course, each
> module would only have its own messages.
---------------------------------------------------------------------
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