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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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]
