[jboss-dev] JBoss Unified I18N Infrastructure

Max Rydahl Andersen max.andersen at redhat.com
Fri Aug 10 14:14:20 EDT 2007


Hi David,

Questions:

Did you look at http://www.icu-project.org/ ? It wasn't in the list of 
alternatives.

Why would I *ever* want to have localized messages inside my code via 
annotations ?

Why do I need to use special components in jsf to get i18n?

Why another log framework ?

Can I use it/integrate within eclipse plugins ?

/max





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




More information about the jboss-development mailing list