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] internationalization
Date Mon, 10 Jul 2006 11:14:22 GMT
 Tim Ellison wrote:
>Mikhail Loenko wrote:
>> 2006/5/25, Tim Ellison <t.p.ellison@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

Hello all!

I'd like to be a volunteer for that.

IMHO it's reasonable to use framework presented in luni module with some
modifications.
To avoid duplication of Msg class I'd suggest use slightly modified Msg
class named let say
o.a.h.luni.utils.ExtMsg.
ExtMsg has the same methods as Msg, the difference is only these methods are
non static,
also specific external messages resource bundle will be initialized by name
in the constructor.
Each module will have class o.a.h.<module>.MsgUtils with static field 'msg'
that is the instance of ExtMsg
initialized with the name of the external messages resource bundle related
to this module.
Thus external message for e.g. security module could be obtained using next
call:

"org.apache.harmony.security.internal.MsgUtils.msg.getString("security.1");"

And at last, place to keep resources with external messages I suppose to be
o.a.h.<module>.internal.

If all these thoughts sounds reasonable, I'd like to implement framework
mentioned above and send you a patch.

--
Thanks,
Ilya Okomin
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message