[jboss-dev] jboss i18n and localization (l10n)

[Max Rydahl Andersen]

>>>> For (1), the translation process, in the Open Source world a lot of
>>> what opensource world is that ? :)
>> LOL
> 
> The non-Java one? :-)

Ok - you mean in Linux development gettext is popular...ok, got it ;)

>>> The built in java method of localization (java ResourceBundles defaults
>>> to use properties, one project I know of using that is Hibernate Search)
> 
> Yup, and gettext should be able to handle the string extraction and 
> conversion of translations to Java ResourceBundles.

good, so wouldn't need extra dependencies in the project.

>>> The other is the way used in e.g. eclipse which uses the (some say
>>> technically better) i18n library developed by IBM which I unfortunately
>>> can't remember the name of now.
> 
> ICU (International Components for Unicode)?

rings a bell ... need to digg deeper to verify.

>> These are things the doc team keep mentioning to me.  They are meant 
>> for full blown translations as in docs.  They seem total overkill for 
>> this, especially 
>  > the PO stuff.
> 
> Not really: .po files are used heavily for software translation, eg 
> localization of GNOME and most GNU projects is entirely based on gettext
> .po files.


>> Java internationalization (no idea about this IBM stuff) is based on 
>> already externalized strings kept in a file separate from the code for 
>> easy translation.

how is that different from gettext? gettext simply uses the original 
string as a key...and if the key is the english wording what happens if 
you correct spellings/wordings in this ? You have to hunt down all the 
.po files?

advantages of "pure" java properties handling is that the ide's (such as 
eclipse) understands them and provides automated support for i18n'ing 
your app (extract the strings and create resource bundle 
references...see the article) and there are more being added 
(refactoring of keys, code completion etc.)

btw. I couldn't figure out from the docs...are there one giant po file 
for all languages or one for each language ? if the original string is 
in there I would assume it was one for all languages since one per each 
would result in alot of duplication of the same key sentence...

> I think the problem with that is that the source, the strings to be 
> translated, and the translationed strings are then all in different 
> places which makes it quite a bit harder to maintain and keep things in 
> sync.

I don't get how this is true....there is key, and N translations, 
exactly the same in resource bundles; please enlighten me ;)