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