>>> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development