harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [drlvm] proposals for VM internationalization
Date Mon, 17 Jul 2006 12:16:28 GMT

Salikh Zakirov wrote:
> Geir Magnusson Jr wrote:
>> I'll state the obvious... there is another thread going on about how do
>> to similar things with Classlib.  Maybe you can find common ground for
>> message bundles and such...
>> geir
> 1. The launcher already packages some translations in property-format,
> it makes me believe that launcher localization was once completed at IBM.
> Though I wasn't able to find anything about localization in launcher sources.

Who cares what was once completed at IBM?  They had their reasons, their
uses... This is Apache Harmony :)  We can do what we feel is best
(including keeping what was donated...)

> Tim, Mark, could you provide more information about localization already implemented
> in classlib natives?
> 2. As far as I can see, the only common thing that natives l10n can have with java l10n
> is translation files. Generally, this is a good goal, as it would make the translators
> more straightforward, keeping the number of formats and message systems at minimum.


> 3. I personally consider the property-based design of l10n in Java inferior, 
> because it requires the keys to be property-name-compatible (e.g. no spaces), and
> it often results in developers choosing to introduce short localization key names
> bearing no meaning. For example, see the harmony_*.properties in classlib:
>    EXEL051=...
> Should the localization system fail, the only thing that user will get is "EXEL051".

Don't we have far bigger problems if the localization system in the JVM

> The developers reading the code which prints localizable message, has no clue too.
> To find out the value of message, one needs to consult default localization file.
> Furthermore, when introducing new localizable message, one needs to edit 3(!) different
> add the message code, add the key, and add the printable message to default localization
> This particular design choice is ineffective in using developers' time, is less robust
> and less maintainable. 
> And if the key names are used in construction of unlocalized messages, then it introduces
> runtime cost of mangling the unlocalized message to some property-name-compatible form.

I understand what you are saying, and certainly agree that if we can
find some way to use meaningful keys, so much the better.  I guess the
question is what does that cost us, versus the likelyhood that the
localization system will fail...


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

View raw message