[jbosstools-dev] Internationalising JBoss Tools

[Rob Stryker]

Honestly, our product has so much code I'd be surprised if the 
translatable strings were really an issue in terms of size.

How many languages do we routinely translate into?  Most of my plugins 
don't have more than 100 translatable strings, and several have much 
less than that.

I think it could be feasible to just include *all* translated 
.properties files in the build with the proper language suffixes and let 
eclipse / NLS load the proper one on their own. If you ever trace 
through NLS you'd see how easy this is actually.

Sean Flanigan wrote:
> Sean Flanigan wrote:
>   
>> Max Rydahl Andersen wrote:
>>     
>>> In here will be a .po file for each plugins "Messages" properties file we  
>>> have.
>>>       
>> Almost.  At the moment, it's one .pot (not po, although they're
>> extremely similar) for virtually every .properties file in the source
>> tree, because the filenames vary too much.  But if they can be
>> refactored so that they're always called Messages.properties, that would
>> be great!
>>     
>
> Let me rephrase that to be less misleading.
>
> Virtually every .properties file in the source tree will generate a
> corresponding .pot file.  ie many .properties -> many .pot files.
>
> At least that's the plan for now.  I'm waiting to hear back from the
> L10n team on how they feel about getting 100+ .pot files, some of which
> will be quite small.  I think most open-source projects have one large
> .pot file, not one per subdirectory (ie Java package).
>
> If I have to, I could map 100 .properties files into one or more .pot
> files, by munging pathnames into the keys (msgctxt).  That would also
> mean a corresponding reduction in the number of .po files.
>
> But I'm hoping to avoid doing that, partly because it's more work! but
> also because it means creating a non-standard mapping between
> pot/po/props.  (At the moment, the mappings implemented by the
> Ant-Gettext tasks correspond to "prop2po --duplicates=msgctxt" in the
> Translate Toolkit.)
>
> Sean.
>