[jboss-dev] JBoss Unified I18N Infrastructure

[Bill Burke]

David also had a cool idea of localizing POJOs and providing 
out-of-the-box editors for documentors for these varies pojos.  For 
example, jmx metadata.

David Ward wrote:
> More responses inline:
> 
> On Fri, 2007-08-10 at 20:51 +0200, Max Rydahl Andersen wrote:
>>>> Did you look at http://www.icu-project.org/ ? It wasn't in the list of 
>>>> alternatives.
>>> Yup.  Actually, ICU is where much of the I18N functionality in the JDK
>>> had been born out of.  Thus, it provides the lower-level functionality
>>> that is leveraged by JBoss I18N - which has a higher-level
>>> applicability.
>> Well Eclipse moved to use icu4j to be more performant (AFAIK) so 
>> something else must be in icu4j ;)
> 
> I'm not surprised.  :)  I'm not really trying to compete with icu4j,
> though.  I'm adding layers on top of functionality it and the JDK both
> provide.  That being said, who knows: if I find something in it I want,
> I might leverage it.
> 
>>>> Why would I *ever* want to have localized messages inside my code via 
>>>> annotations ?
>>> You don't have to; it is a feature.  If you don't, however, you will
>>> have to "lookup" your L10N values rather than having them be handed to
>>> you per the current "LocalizationContext".
>> But the whole process of having doc writers translate your text would be 
>> pretty cumbersome with the translations in code and not to talk about 
>> the amount of extra lines added to the code ...?
> 
> I personally don't like having translations in the code - that's why I
> would rather see people (an "L10N data maintainer" role) use the
> i18n-console to manage L10N data in a separate Repository.  The reason I
> put in the ant integration (ala BundleTask) is for those out there who
> actually "want" their translations in the code.  Just trying to offer
> choice.
> 
>>>> Why another log framework ?
>>> I know, I know, I know.  Everyone and their brother has at one time or
>>> another written a log abstraction framework.  Some of them do some
>>> pretty cool stuff - Seam's in particular (it handles Component
>>> interpolation).  The problem is that to log I18N messages, one would
>>> have to look up the bundle, get out a string, then log it.  With JBoss
>>> I18N Log, it is one step - just pass in the "code" of the I18N object to
>>> the log statement (as well as any vararg parameters).  Now, Mazz has a
>>> SourceForge project that can do this, as does JBoss Transactions - so I
>>> took the best from both and added it to JBoss I18N.  Again, I'm trying
>>> to unify everyone's efforts here into something not tied to any one
>>> particular project.
>> ok
>>
>>>> Can I use it/integrate within eclipse plugins ?
>>> The core JBoss I18N library has no dependencies whatsoever on a
>>> "container" like an appserver.  So yes, you can use it in standalone
>>> applications and eclipse plugins (although I haven't tried it via an
>>> eclipse plugin yet).
>> What eclipse does is to not do the lookups or injections at runtime but 
>> when the classes loads and the actual strings are stored into a constant 
>> string e.g.
>>
>> class Messages {
>>     String I18N_JPA_ERROR_MSG;
>>      ...
>> }
>>
>> and then you access that string directly. This "trick" saved several 
>> megabytes of heap when Eclipse is running plus removes the 
>> lookup/injection overhead.
> 
> It's cool you brought this up.  I have been thinking seriously of using
> bytecode manipulation to make the same thing happen (leveraging the
> other core JBoss I18N services) dynamically on field access.  A couple
> differences, though: 1) it would work for any kind of POJO - not just
> Strings, and 2) what is stored is not [just] the actual value, but an
> object that can change a managed value depending on a Locale context
> change.  All the underlying pieces to support this are done, I would
> just have to add in the "hook".
> 
>> /max
> ...
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com