Re: [jboss-dev] JBoss Unified I18N Infrastructure
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(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