Caius Carlos Chance wrote: > >>> Another advantage of using gettext is, there is an existing >>> localization team in Red Hat could be leveraged for the all JBoss >>> modules when the I18N infrastructure on JBoss could be integrated >>> with current workflow (e.g. tools, work file formats, etc.) of them. >>> They have done the translation for JBoss Installer and they are very >>> familiar on working with .po files that are used by gettext. >>> >> Sure, but requiring the projects to add an additional 3rd party jar >> is wrong (especially one I've never seen used in java) >> Would be relevant to know how the java properties support would work... >> > It will be good idea if all modules could unify their I18N > infrastructure. If so, also there would be only 1 convertor needed to > be developed for the translation team. The development of the > convertor may allow both translation team and current jboss developer > keep minimal changes on workflow/code. +1 for unification if the "standard" doesn't suck. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Sorry, I just joined the jboss-development list, so I don't know the full context for this email thread. Bill is including me 'cause he knows I've done a significant amount of work on a project I would like to lead, called "JBoss I18N". Sacha also knows about it, and has asked Mark to give it a look-see. If anyone has any questions about it, I would be glad to answer. In the meantime, Sacha has suggested I create a public WIKI page and attach the PDF overview presentation I had previously created. So, here it is: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossI18N Best regards, David JBoss Solutions Architect On Fri, 2007-08-10 at 08:48 -0400, Bill Burke wrote: > Then David should be involved. > > Thomas Heute wrote: >> Caius Carlos Chance wrote: >>>>> Another advantage of using gettext is, there is an existing >>>>> localization team in Red Hat could be leveraged for the all JBoss >>>>> modules when the I18N infrastructure on JBoss could be integrated >>>>> with current workflow (e.g. tools, work file formats, etc.) of them. >>>>> They have done the translation for JBoss Installer and they are very >>>>> familiar on working with .po files that are used by gettext. >>>>> >>>> Sure, but requiring the projects to add an additional 3rd party jar >>>> is wrong (especially one I've never seen used in java) >>>> Would be relevant to know how the java properties support would work... >>>> >>> It will be good idea if all modules could unify their I18N >>> infrastructure. If so, also there would be only 1 convertor needed to >>> be developed for the translation team. The development of the >>> convertor may allow both translation team and current jboss developer >>> keep minimal changes on workflow/code. >> +1 for unification if the "standard" doesn't suck. >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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

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

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

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

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

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

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

Hi David, David Ward wrote: > I've done a significant amount of work on a project I would like to > lead, called "JBoss I18N". Sacha also knows about it, and has asked > Mark to give it a look-see. If anyone has any questions about it, I > would be glad to answer. In the meantime, Sacha has suggested I create > a public WIKI page and attach the PDF overview presentation I had > previously created. So, here it is: > http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossI18N Ok thanks. Do you have any example code or projects using your i18n framework to have a better idea of how it looks? Thanks, Jens