harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm] proposals for VM internationalization
Date Tue, 18 Jul 2006 12:02:00 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.
> 
> Tim, Mark, could you provide more information about localization already implemented
> in classlib natives?

There is support for getting localized messages from resource files in
the Harmony port library functions.

See:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/hynls_8c.html?view=co


Regards,
Tim

> 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
job
> 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".
> 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
places:
> add the message code, add the key, and add the printable message to default localization
file.
> 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.
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

-- 

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


Mime
View raw message