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 Wed, 12 Jul 2006 06:38:52 GMT
Not it will have special handling just for English locale. This
special handling will say that we do need to load something.

Why do you think it will take more memory for non-English locales?

SY, Alexey

2006/7/12, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> -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
>
>


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