[jbosstools-dev] Internationalising JBoss Tools

[Max Rydahl Andersen]

> 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