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 Wed, 12 Jul 2006 08:27:42 GMT
On 7/11/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>
>
>
> Tim Ellison wrote:
> > Ilya Okomin wrote:
> >> I'd like to be a volunteer for that.
> >
> > I just started working in this area (for SQL), maybe that is what
> > prompted you...<g>
> >
> >> 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");"
> >
> > I see your point, and considered doing it that way too.  I'm not overly
> > concerned about the duplication, they are trivial helper methods anyway,
> > and we all know that singletons are evil ;-)
>
> I don't understand this, given you have one...
>
> >
> >> And at last, place to keep resources with external messages I suppose
> to be
> >> o.a.h.<module>.internal.
> >
> > I went for o.a.h.<module>.internal.nls just to keep them tidy.
> >
> >> If all these thoughts sounds reasonable, I'd like to implement
> framework
> >> mentioned above and send you a patch.
> >
> > The real work is going through and externalizing all the messages, and
> > if I were to be really ambitious to add messages to all the exceptions
> > that we throw that don't have anything right now.
> >
> > Patches are always welcome.  We can work on that that as we finalize on
> > the framework.
>
> Have you had any thoughts about a 'common' code set, that is copied and
> modified at build time, setting the right package name and bundle name
> by convention?  That would remove the need to duplicate the code.


Yep, it is a good idea that we can use. However, in approach that I
described here we only need to create MsgUtils class in each module where
ExtMsg class static instance is to be initialized. In my opinion there is
not so much work to do manually once and not to make build config files more
complex.


> geir
>
>
> ---------------------------------------------------------------------
> 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