3:24 a.m.
Hi,
Handling plurals in an internationalized way is something of an unsolved
problem in Java, at least in Eclipse circles.
Here's some code I found in DefaultWizardDataValidator.java [1].
message = DefaultCreateHandler.title(parent, true) +
" can contain only " + max +
((max == 1) ? " child " : " children ") +
"with entity " + entity + ".";
I'm not sure whether the XModel needs i18n, but that's a subject for my
other email. Here, it's just an example.
Now I can use MessageFormat to construct the strings like this:
message = ((max == 1) ?
MessageFormat.format(
"{0} can contain only {1} child with entity {2}.",
DefaultCreateHandler.title(parent, true), max, entity)
: MessageFormat.format(
"{0} can contain only {1} children with entity {2}.",
DefaultCreateHandler.title(parent, true), max, entity));
but that only tends to work for Germanic languages, since every language
has different rules for plurals, and even differing numbers of plural
forms[2]:
http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
There's a few ways we can deal with this sort of thing:
1. Use a clunky workaround like:
"{0} can contain only {1} child(ren) with entity {2}."
2. Reformulate [3] the sentence, perhaps like this:
"Parent has too many children with entity. Parent: {0}, Number of
children: {1}, Entity {2}"
3. Use ICU's PluralFormat [4] support:
com.ibm.icu.text.MessageFormat.format(
"{1, plural, " +
"one {{0} can contain only # child with entity {2}.} " +
"other {{0} can contain only # children with entity {2}.}}",
new Object[] {parent, max, entity});
4. Use Gettext's plural support[5], by using
gnu.gettext.GettextResource.ngettext() instead of
java.util.ResourceBundle.getString(). Actually, we can't really use
libgettext as is [6], but we could borrow the plural handling (it's
LGPL) and use it with Eclipse's Messages classes or ResourceBundles.
I18n.ngettext(Messages.class, "TOO_MANY_CHILDREN", a, b, c);
where the English messages.properties might be
TOO_MANY_CHILDREN_0={0} can contain only one child with entity {2}.
TOO_MANY_CHILDREN_1={0} can contain only {1} children with entity {2}.
or
I18n.ngettext(Messages.TOO_MANY_CHILDREN, a, b, c);
where the English messages.properties might be
TOO_MANY_CHILDREN={0} can contain only one child with entity {2}.\
|{0} can contain only {1} children with entity {2}.
Option 1 is commonly used, but ugly across all languages.
I think option 2 deserves consideration. Yes, it's a workaround, and
reformulating the sentences may be difficult, but I think the result
will often be clearer than the original, even in English. (If the above
example isn't clear, it's probably because I didn't understand the
original in context.) Using this workaround may avoid the need for
options 3 and 4.
Option 3 is pretty strong in some ways, since ICU comes with Galileo,
and it seems to be very complete. ICU even comes with predefined plural
rules built-in for a number of languages. However, the translation
strings end up being almost unreadable, which makes them almost
untranslatable.
Option 4 can work, but will require solving some technical issues. For
instance, either we encode 1-4 plural forms into a single resource
bundle string (with some sort of delimiter, which leads to edge cases)
or we generate resource keys at runtime to look up the plural we want
(which means Eclipse's wizards thinks those resource keys are unused).
It may also be appropriate to use option 2 for some messages, and option
3/4 in cases where option 2 is not good enough.
Opinions?
Sean.
[1]
http://anonsvn.jboss.org/repos/jbosstools/trunk/common/plugins/org.jboss....
[2] http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
[3]
http://globalizer.wordpress.com/2007/01/30/how-to-use-choiceformat-then-l...
[4]
http://bugs.icu-project.org/apiref/icu4j/com/ibm/icu/text/PluralFormat.html
[5]
http://www.gnu.org/software/gettext/manual/html_node/javadoc2/gnu/gettext...
[6] The Gettext API expects the ResourceBundle keys to be the actual
English text, not a made-up key. This doesn't match the Eclipse
approach with Messages classes where key is a field name.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
5:11 a.m.
There's a few ways we can deal with this sort of thing:
1. Use a clunky workaround like:
"{0} can contain only {1} child(ren) with entity {2}."
Clunky, but
it at least states the reason why the error/warning is
happening.
2. Reformulate [3] the sentence, perhaps like this:
"Parent has too many children with entity. Parent: {0}, Number
of children: {1}, Entity {2}"
I don't think this is a clear message,
compared to #1.
3. Use ICU's PluralFormat [4] support:
com.ibm.icu.text.MessageFormat.format(
"{1, plural, " +
"one {{0} can contain only # child with entity {2}.} " +
"other {{0} can contain only # children with entity {2}.}}",
new Object[] {parent, max, entity});
they encode the plural rules into one
string ?
4. Use Gettext's plural support[5], by using
gnu.gettext.GettextResource.ngettext() instead of
java.util.ResourceBundle.getString(). Actually, we can't really use
libgettext as is [6], but we could borrow the plural handling (it's
LGPL) and use it with Eclipse's Messages classes or ResourceBundles.
I18n.ngettext(Messages.class, "TOO_MANY_CHILDREN", a, b, c);
How much
code is that plural handling ?
Is it worth the trouble when we can't ensure all the plugins we use will
be able to use it ? (3rd party plugins would at most just use #3)
And how many places do we have to actually handle plural ?
I think option 2 deserves consideration. Yes, it's a workaround,
and
reformulating the sentences may be difficult, but I think the result
will often be clearer than the original, even in English. (If the
above example isn't clear, it's probably because I didn't understand
the original in context.) Using this workaround may avoid the need
for options 3 and 4.
Agreed, just need a better message ;)
/max
9 p.m.
On 06/19/2009 08:11 PM, Max Rydahl Andersen wrote:
>
> There's a few ways we can deal with this sort of thing:
>
> 1. Use a clunky workaround like:
> "{0} can contain only {1} child(ren) with entity {2}."
Clunky, but it at least states the reason why the error/warning is
happening.
In English it might (state the reason), *if* you understand the context.
I wouldn't bet on it stating anything useful after translation, since
translators won't have the context unless they chase it up with the
programmer.
It's just as well Slava said XModel doesn't need translation, for the
most part!
> 2. Reformulate [3] the sentence, perhaps like this:
> "Parent has too many children with entity. Parent: {0}, Number
> of children: {1}, Entity {2}"
I don't think this is a clear message, compared to #1.
Well, that's why I said "perhaps"! Another option:
"Parent {0} has too many children with entity {2}. Maximum children: {1}"
I still don't really know what it means (children with entity?!), but
it's closer to the original. I think the main thing is to get the
conditional plural out of the sentence.
But you're right, it's pretty difficult to remove the plural from this
sentence without changing it for the worse (*in English*). But it may
be worth paying this price if it lets us skip options 3 and 4, at least
for now.
> 3. Use ICU's PluralFormat [4] support:
> com.ibm.icu.text.MessageFormat.format(
> "{1, plural, " +
> "one {{0} can contain only # child with entity {2}.} " +
> "other {{0} can contain only # children with entity {2}.}}",
> new Object[] {parent, max, entity});
they encode the plural rules into one string ?
Yep, it's a very general solution, but hard to read, even for a
programmer, let alone a translator. You should read the example in the
Javadoc!
http://bugs.icu-project.org/apiref/icu4j/com/ibm/icu/text/PluralFormat.html
I do think putting everything into one string is the most practical
solution in Java, since otherwise you have different numbers of strings
for your different locales. Gets complicated, especially if you like
Eclipse's i18n wizards.
I'd be all for ICU, if it just allowed simpler strings for the
translators to deal with. And if I could find any documentation other
than the javadoc above. I haven't even found a proper list of the
supported plural forms for French, for example.
> 4. Use Gettext's plural support[5], by using
> gnu.gettext.GettextResource.ngettext() instead of
> java.util.ResourceBundle.getString(). Actually, we can't really use
> libgettext as is [6], but we could borrow the plural handling (it's
> LGPL) and use it with Eclipse's Messages classes or ResourceBundles.
> I18n.ngettext(Messages.class, "TOO_MANY_CHILDREN", a, b, c);
How much code is that plural handling ?
A lot more than I realised. GettextResource.java is pretty short -
http://cvs.savannah.gnu.org/viewvc/gettext/gettext-runtime/intl-java/gnu/...
- but now that I dig into the code, I realise that it really depends on
the generated code from write-java.c
http://cvs.savannah.gnu.org/viewvc/gettext/gettext-tools/src/write-java.c...
It actually generates Java code from the plural rules for each locale.
I was expecting to find a simple plural rule interpreter I could easily
borrow, but I can see why they might want to use compiled code. That
won't work for us unless we start generating & compiling our
ResourceBundles too...
So it might actually be less trouble to convert from a simple string
format (for translators) into the ICU plural format. But that's not to
say it would be easy. It might be very easy to get it wrong...
Is it worth the trouble when we can't ensure all the plugins we
use will
be able to use it ? (3rd party plugins would at most just use #3)
Well, no, we can't. It's just for JBT code. And it could be a lot of
trouble. I'm just listing all the options, but I like option 2.
Based on a quick grep of the Babel langpacks, none of the Eclipse
projects have used ICU's plural support. I suspect (a) they haven't
considered the problem of non-Germanic plurals, (b) they rolled their
own solution, or (c) they went with something like option 2.
And how many places do we have to actually handle plural ?
I have no way of knowing until I find them. I've only found a few so
far, but there are a lot more strings I haven't looked at.
I'm hoping there won't be many. I think you would get many more full
grammatical sentences in, say, a business application than in a
development tool. They tend to be terser.
> I think option 2 deserves consideration. Yes, it's a
workaround, and
> reformulating the sentences may be difficult, but I think the result
> will often be clearer than the original, even in English. (If the
> above example isn't clear, it's probably because I didn't understand
> the original in context.) Using this workaround may avoid the need
> for options 3 and 4.
Agreed, just need a better message ;)
Exactly. Now what on earth does the original message mean?
I'll make sure I refer any other de-pluralizations I'm not sure about.
They should be rare enough that it makes sense to give them individual
JIRAs. I hope.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
5678
days inactive
5681
days old
jbosstools-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Max Rydahl Andersen -
Sean Flanigan