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 09:01:28 GMT
2006/7/12, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
> Not it will have special handling just for English locale. This
> special handling will say that we do need to load something.
>
Well, a locale consists of several parameters, not only language.
Anyway, the argument is to avoid any exceptional cases and keep it
simple and stupid.

> Why do you think it will take more memory for non-English locales?
Bcause of longer keys to a bundle - compare "a123" and "The
application has requested unusual operation and should be slated."

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

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