[jbosstools-dev] Internationalising JBoss Tools

[Rob Stryker]

what exactly is a .po file and how are they structured?

Max Rydahl Andersen wrote:
>> 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 ?
>
>