Re: [jbosstools-dev] Internationalising JBoss Tools
I've been working on a solution that would make it easy for the
Red Hat
L10n team to translate JBoss Tools and then include the translations in
JBoss Tools.
Glad to hear it is still moving forward!
I now think that we do need file conversion as part of the build.
To
avoid the problem of conflicting translations, I would recommend that
all translations apart from English live as PO files in the source tree,
and their .properties will only be generated as build/runtime artifacts.
Okey - if that could be done making the "main" builds more or less
unaffected
of the translations that would be great.
The generated .properties files /could/ be stored in the source
tree
for convenience if preferred, but in any case I think it's best that all
edits happen in the PO files.
Okey.
I did consider converting from properties to PO, so that we could
have
only properties files in the source tree, not POT/PO, but properties
files don't contain important metadata which is available in PO files
and used by translators to manage workflow, re-use translations, verify
that MessageFormat strings haven't been broken, etc.
Okey.
And remember, you can't even put Unicode characters in a
.properties
file without using native2ascii or a special editor. With PO, you can
use a special Gettext editor if you like, but PO is perfectly happy to
be UTF-8, and editable with any text editor.
Okey ;)
I have created a pure Java Ant task (prop2pot) which can generate
(from
the English .properties files in the source tree) the translation
templates (POT) to give to Red Hat's L10n team.
The L10n team would then translate the POT files into PO files which
contain the translations.
I have another task po2prop which can generate .properties files from PO
files, but I'm still working on po2frag, which will package .properties
files as plugin fragments, to use as language packs. I have a kludgy
shell script which seems to work, but it really needs to be pure Java if
it's going to be part of the build. I would appreciate some help with
making the Java version less kludgy, since I'm quite new to OSGi bundles.
Let me see if we can translate this into operational terms ;)
Got any suggestions on how we structure this and get implemented ?
Do we for example add a i18n subfolder in each module that needs
translation (today we have docs, tests, plugins, features)
i.e. /trunk/hibernatetools/i18n
In here will be a .po file for each plugins "Messages" properties file we
have.
There will also be a build that generates a fragment (or is it
fragement*s*, one for each plugin ?)
Then if that generates into /trunk/hibernatetools/i18n/build/fragments
users who want to see the translations
just need to run the generation and import the fragments from there ?
Or do you see us create the fragments explicitly in e.g.
/trunk/hibernatetools/i18n and have a build for each of these
that goes from .pto to the properties files ? (the property files will not
be committed, only be generated) ?
And how are these going to be grouped ? One set per language or One set
for all languages/group of languages ?
--
/max