[jboss-dev] JBoss Unified I18N Infrastructure

[David Ward]

More inline...

On Fri, 2007-08-10 at 21:25 +0200, Max Rydahl Andersen wrote:
> >>>> 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 ?

It's all about choice.  I don't want to force something down everyone's
throats.  If you want your Strings in your code, you can.  If you want
them next to your code, you can.  If you want them in a database (or
anything else that JCR provides access to), you can.

And it's not limited to Strings.

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

That's fine, but it's certainly not desirable or acceptable for *all*
apps.  Choice man.  Choice.  :) :) :)