[jboss-dev] JBoss Unified I18N Infrastructure

[Max Rydahl Andersen]

>>>> 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.  

huh ? that makes no sense to me ;)

Why wouldn't you like to have the majority of the translated strings in 
the same svn repository next to the project/product they matches ?

 > 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.

>>>> 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".

This is actually what eclipse want'ed to avoid...they just wanted *one* 
langugage loaded and no extra lookups since it was actually using alot 
of memory and cpu to handle this stuff.

For standalone apps of the size of Eclipse a restart is an acceptable 
way of changing language.

/max

>> /max
> ...
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development