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 <[EMAIL PROTECTED]>:
-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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > > Yep, it's an interesting idea. > > I like it! > > > > SY, Alexey > > > > 2006/7/10, Alexey Varlamov <[EMAIL PROTECTED]>: > > > 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 <[EMAIL PROTECTED]>: > > > > Tim Ellison wrote: > > > > >Mikhail Loenko wrote: > > > > >> 2006/5/25, Tim Ellison <[EMAIL PROTECTED] >: > > > > >>> 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 ( [EMAIL PROTECTED] ) > > > > >IBM Java technology centre, UK. > > > > > > > > > >--------------------------------------------------------------------- > > > > >Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Alexey A. Petrenko Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
