[jboss-dev] JBoss Unified I18N Infrastructure

[David Ward]

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