harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [classlib] internationalization
Date Mon, 10 Jul 2006 11:49:18 GMT
Yep, it's an interesting idea.
I like it!

SY, Alexey

2006/7/10, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> Ilya,
>
> I'd also suggest you to look at
> http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html.
> It describes quite smart approach for using message bundles, we could
> go in the similar direction.
>
> --
> Alexey Varlamov
>
>
> 2006/7/10, Ilya Okomin <ilya.okomin@gmail.com>:
> >  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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Alexey A. Petrenko
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


Mime
View raw message