harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [classlib] internationalization
Date Wed, 12 Jul 2006 05:18:16 GMT
-1 for hardcoded English messages. This introduces need for special
handling of certain locales and increases memory waste for non-English
locales.

2006/7/10, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
> As evolution of this idea I can suggest to create Messages class with
> English messages instead of empty strings. There are few benefits:
> 1. We do not need to load property file for C (English) locale. This
> will improve startup time for this locale.
> 2. It will be impossible to forget to add a message for a new variable :)
> 3. If property is not defined for particular locale we will use
> message in English.
>
> Thoughts?
>
> SY, Alexey
>
> 2006/7/10, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
> > 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
> >
>
>
> --
> 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
>
>

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