[jbosstools-dev] Internationalising JBoss Tools

[Max Rydahl Andersen]

http://www.google.com/search?q=po+file

:)

extra info: .po is what the documetnation team at red hat/fedora uses for  
localization.

/max

> 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 ?
>>
>>
>



-- 
/max