3:49 a.m.
Hi,
I would like to ask about and start some discussion about localization
(translation) of JBoss projects.
I think there is going to be an increasing need for localization of
JBoss projects, so probably it is a good time to start thinking about
how to do internationalization of projects in a way that is optimal for
developers, translators and users. I think there are two sides to this:
(1) the process of getting translations done and integrated into svn and
releases and (2) the java library used to substitute the translations at
runtime.
For (1), the translation process, in the Open Source world a lot of
translation is done using .po files. First the strings that need to be
translated are extracted from the source using xgettext to generate a
so-called POT file, which is the skeleton used to generate the .po files
for each language that is to be translated. Finally the translated .po
files are committed in the version control system along with the
ResourceBundles generated from them.
(2) would then require using Gettext in the Java modules that require
translations and marking the strings to be translated appropriately so
that they can be extracted automatically for translation.
That is a brief sketch of how would could use Gettext to handle the
translations. It might also be possible to use XLiff later to generate
the ResourceBundles for translations directly.
How does that idea sound?
Ideas, comments, other suggestions and feedback are most welcome.
Jens Petersen
Internationalization Team
Red Hat
3:57 a.m.
For (1), the translation process, in the Open Source world a lot of
what opensource world is that ? :)
In Java I know of two major ways:
The built in java method of localization (java ResourceBundles defaults
to use properties, one project I know of using that is Hibernate Search)
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.
(2) would then require using Gettext in the Java modules that require
translations and marking the strings to be translated appropriately so
that they can be extracted automatically for translation.
what is Gettext?Xliff?
/max
7:56 a.m.
On Friday 27 July 2007 03:57:14 am Max Rydahl Andersen wrote:
> For (1), the translation process, in the Open Source world a lot
of
what opensource world is that ? :)
LOL
In Java I know of two major ways:
The built in java method of localization (java ResourceBundles defaults
to use properties, one project I know of using that is Hibernate Search)
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.
> (2) would then require using Gettext in the Java modules that require
> translations and marking the strings to be translated appropriately so
> that they can be extracted automatically for translation.
what is Gettext?Xliff?
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. 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.
8:33 a.m.
> In Java I know of two major ways:
>
> The built in java method of localization (java ResourceBundles defaults
> to use properties, one project I know of using that is Hibernate Search)
>
> 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.
>
>> (2) would then require using Gettext in the Java modules that require
>> translations and marking the strings to be translated appropriately so
>> that they can be extracted automatically for translation.
> what is Gettext?Xliff?
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. 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.
what is that PO stuff?
The IBM stuff is using the same files and naming conventions of java,
but is less broken (long story - but eclipse needed to move to it for
not running out of memory ;)
/max
8:20 p.m.
Max Rydahl Andersen writes:
what is that PO stuff?
PO files are pretty simple:
http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files
Basically they are text files carrying the original text and their
translations made by the translator. Our translators have tools
for and are quite familiar with working with them.
Jens
1:58 a.m.
> what is that PO stuff?
PO files are pretty simple:
http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files
Basically they are text files carrying the original text and their
translations made by the translator. Our translators have tools
for and are quite familiar with working with them.
...but does our (the other part of the Open Source World) community have
access to it ? Is it cross platform (linux,windows,mac or in short java ?)
/max
3:54 a.m.
Max Rydahl Andersen wrote:
>> what is that PO stuff?
>
> PO files are pretty simple:
> http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files
>
> Basically they are text files carrying the original text and their
> translations made by the translator. Our translators have tools
> for and are quite familiar with working with them.
...but does our (the other part of the Open Source World) community have
access to it ? Is it cross platform (linux,windows,mac or in short java ?)
We used po stuff to translate the diffrent JBoss AS guides in French,
using Mac, Windows and Linux, so yes you have the tools, and i actually
'liked' the tools, it's not perfect but better than dealing with plain
docbook.
The advantages i could notice:
- possibility to 'mark' keys as dirty (need rework)
- possibility to add bookmarks if i remember well
- easy to see what is not yet translated
But i'm pretty relectant to use gettext for JBoss Portal localization.
Also, it's still a pure translation tool, not something that would help
you keep your code in sync with the property files for example.
Now you mentioned tools for Eclipse, i'm curious to hear about. I never
looked at this. You mentionned an article ? Which one ?
4:21 a.m.
Thomas Heute wrote:
Max Rydahl Andersen wrote:
>>> what is that PO stuff?
>>
>> PO files are pretty simple:
>> http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files
>>
>> Basically they are text files carrying the original text and their
>> translations made by the translator. Our translators have tools
>> for and are quite familiar with working with them.
>
> ...but does our (the other part of the Open Source World) community
> have access to it ? Is it cross platform (linux,windows,mac or in
> short java ?)
We used po stuff to translate the diffrent JBoss AS guides in French,
using Mac, Windows and Linux, so yes you have the tools, and i actually
'liked' the tools, it's not perfect but better than dealing with plain
docbook.
ok, cool. any docs that explains the tools without having to install and
run them ?
The advantages i could notice:
- possibility to 'mark' keys as dirty (need rework)
- possibility to add bookmarks if i remember well
- easy to see what is not yet translated
But i'm pretty relectant to use gettext for JBoss Portal
localization.
exactly ;)
In eclipse it would be against everything else so at runtime it should
be properties.
Also, it's still a pure translation tool, not something that
would help
you keep your code in sync with the property files for example.
Now you mentioned tools for Eclipse, i'm curious to hear about. I
never
looked at this. You mentionned an article ? Which one ?
hmm - i thought I had already posted it...anyway:
http://www.ibm.com/developerworks/opensource/library/os-i18n/
http://www.eclipse.org/articles/Article-Internationalization/how2I18n.html
Most of it is related to plugins, but the externalize strings should be
applicable to any kind of i18n work.
/max
1:26 p.m.
Steve Ebersole wrote:
> what is Gettext?Xliff?
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. 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.
GNU Gettext is a portable localization API. It's main advantage over
Java i8ln is that it can handle the plural form problem.
For example:
System.out.println(num + " file(s) changed");
This doesn't map well to other languages because many of them have
different rules for plurals (some have as many as 3 with a special form
for zero).
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
1:36 p.m.
Jason T. Greene wrote:
Steve Ebersole wrote:
>> what is Gettext?Xliff?
> 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. 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.
GNU Gettext is a portable localization API. It's main advantage over
Java i8ln is that it can handle the plural form problem.
For example:
System.out.println(num + " file(s) changed");
This doesn't map well to other languages because many of them have
different rules for plurals (some have as many as 3 with a special form
for zero).
huh ? java localization has plural handling:
http://java.sun.com/docs/books/tutorial/i18n/format/choiceFormat.html
What else does gettext do ?
...and since its under GPL we can't really use it...so...
/max
1:47 a.m.
Jens Petersen wrote:
Max Rydahl Andersen さんは書きました:
> ...and since its under GPL we can't really use it...so...
How about LGPL? (libintl.jar (gnu.gettext) is under LGPL.)
LGPL is fine.
/max
Jens
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
8:35 p.m.
Max Rydahl Andersen さんは書きました:
> System.out.println(num + " file(s) changed");
>
> This doesn't map well to other languages because many of them have
> different rules for plurals (some have as many as 3 with a special
> form for zero).
huh ? java localization has plural handling:
http://java.sun.com/docs/books/tutorial/i18n/format/choiceFormat.html
But this requires actually writing a little code to handle that.
Gettext .po files can handle plurals directly without needing to
write any extra code by hand.
What else does gettext do ?
Another nice thing about gettext is that the original English strings
are kept in the source file - no need to use string labels for strings.
And .po files which contain a copy of the original strings and their
translations next to them are much easier for translators to work with.
Jens
2:02 a.m.
> huh ? java localization has plural handling:
> http://java.sun.com/docs/books/tutorial/i18n/format/choiceFormat.html
But this requires actually writing a little code to handle that.
Gettext .po files can handle plurals directly without needing to
write any extra code by hand.
okey...that's a nice thing but in the big picture I would say it's a
minor one.
> What else does gettext do ?
Another nice thing about gettext is that the original English strings
are kept in the source file - no need to use string labels for strings.
this just translates to "use the original string as the key" practice,
correct ?
/max
9:30 a.m.
Max Rydahl Andersen wrote:
>> huh ? java localization has plural handling:
>> http://java.sun.com/docs/books/tutorial/i18n/format/choiceFormat.html
>
> But this requires actually writing a little code to handle that.
> Gettext .po files can handle plurals directly without needing to
> write any extra code by hand.
okey...that's a nice thing but in the big picture I would say it's a
minor one.
The problem is, as I mentioned some languages have more forms than just
2 (singular and plural) noun forms, The ChoiceFormat approach would
require either a) application knowledge of the language, which is a
broken abstraction or b) a property lookup for all numbers 1-10 (not
practical).
Perhaps this isn't important for the languages we are targeting. I just
wanted to point out that gettext is actually a well thought out framework.
-Jason
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
7:49 p.m.
Steve Ebersole wrote:
On Friday 27 July 2007 03:57:14 am Max Rydahl Andersen wrote:
>> For (1), the translation process, in the Open Source world a lot of
> what opensource world is that ? :)
LOL
The non-Java one? :-)
> 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.
> 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)?
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.
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.
Jens
--
Jens Petersen
Internationalization Team
Red Hat
1:57 a.m.
>>> 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 ;)
8:04 p.m.
Max Rydahl Andersen writes:
what is Gettext?Xliff?
Gettext is the GNU http://www.gnu.org/software/gettext/
which provides a set of tools for extracting, maintaining
and compiling translation message catalogs.
XLIFF (OASIS XML Localisation Interchange File Format) provides
an XML format for handling translations:
http://www.oasis-open.org/committees/xliff/faq.php
Jens
4:25 a.m.
btw. the IBM "thing" was ICU4J: http://wiki.eclipse.org/ICU4J and
http://icu-project.org/
But I don't know much details about it except it's using the same api as
the jdk (except it now lives in a different package)
/max
> For (1), the translation process, in the Open Source world a lot
of
what opensource world is that ? :)
In Java I know of two major ways:
The built in java method of localization (java ResourceBundles defaults
to use properties, one project I know of using that is Hibernate Search)
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.
> (2) would then require using Gettext in the Java modules that require
> translations and marking the strings to be translated appropriately so
> that they can be extracted automatically for translation.
what is Gettext?Xliff?
/max
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:34 a.m.
There are a couple of approaches that we are currently using in some
projects for I18N/L10N compliance (and one of them is documented in
the developer's guide):
(i) JBossTS uses the I18N/L10N framework developed by HP in 2000 to
do automatic generation of resource bundles and logging within the
code you use them. Although we only have English RBs at the moment,
in the past we've had over a dozen different translations.
(ii) David Ward has been working on a new project for
internationalization that uses some of the ideas in (i), but is more
of a superset approach. Sacha asked me to work with David on
requirements and useability (amongst other things) with a view to
developing something that all of our projects can use. It's a slow
process, given other factors.
Take a look at (i) (it's all in public svn) and talk to David.
Mark.
On 27 Jul 2007, at 09:49, Jens Petersen wrote:
Hi,
I would like to ask about and start some discussion about
localization (translation) of JBoss projects.
I think there is going to be an increasing need for localization of
JBoss projects, so probably it is a good time to start thinking
about how to do internationalization of projects in a way that is
optimal for developers, translators and users. I think there are
two sides to this: (1) the process of getting translations done and
integrated into svn and releases and (2) the java library used to
substitute the translations at runtime.
For (1), the translation process, in the Open Source world a lot of
translation is done using .po files. First the strings that need
to be translated are extracted from the source using xgettext to
generate a so-called POT file, which is the skeleton used to
generate the .po files for each language that is to be translated.
Finally the translated .po files are committed in the version
control system along with the ResourceBundles generated from them.
(2) would then require using Gettext in the Java modules that
require translations and marking the strings to be translated
appropriately so that they can be extracted automatically for
translation.
That is a brief sketch of how would could use Gettext to handle the
translations. It might also be possible to use XLiff later to
generate the ResourceBundles for translations directly.
How does that idea sound?
Ideas, comments, other suggestions and feedback are most welcome.
Jens Petersen
Internationalization Team
Red Hat
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
----
Mark Little
mlittle(a)redhat.com
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
6352
days inactive
6355
days old
jboss-development@lists.jboss.org
19 comments
6 participants
participants (6)
-
Jason T. Greene -
Jens Petersen -
Mark Little -
Max Rydahl Andersen -
Steve Ebersole -
Thomas Heute