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 job > more straightforward, keeping the number of formats and message systems at > minimum. +1 > > 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 fails? > 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. 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... geir --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
