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.