Re: [jboss-dev] JBoss Unified I18N Infrastructure
> 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 ;)
> 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 ...?
> 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.
/max