Plurals should be my choice, not the Locale's

[Matt Bishop]

I spent a couple of fruitless hours yesterday trying to get plurals to
work the way I wanted them to with the new Plural API. After digging
through the source code (never a good sign) I discovered that I have
to accept GWT's notion that '0' is a plural in the English language.

Really? Zero? None?

Technically, yes, none is plural: there is one egg, there are two
eggs, there are no eggs. However, I wanted this kind of messaging:

Found 1 result.
Found 23 results.
No results found.

With the Plural API, I found myself writing my own PluralRule so I
could trigger the magical DefaultRule_0_1_n class myself. This is not
to mention that it never worked--GWT would not pick up that rule no
matter what DefaultLocale I picked.

So this morning over my cappuccino I came to the conclusion that GWT
is mistakenly joined two concerns that should not be joined, namely
Plurals and L10N. Instead of being fused together, it makes more sense
for Plurals to use the resource bundles, but for the definition of
what plurals to use for a given string should be controlled by how one
defines the resource. I'd love this:

public String resultsCount(@PluralText int count);

//in props file:
resultsCount = Found {0} results
resultsCount[0] = No results found
resultsCount[1] = Found 1 result

And then; in the same files:

public String shots(@PluralText int count)

shots = {0}-shot espresso
shots[0] = Steamed milk?
shots[1] = Single espresso
shots[2] = Double espresso
shots[3] = Triple espresso
shots[4] = Quad me baby!

You see, I have different ideas in different contexts as to what the
plurals should be.

I may or may not have these same ideas given a different language, but
that that property file can be different. That's a separate concern
and should be dealt with separately.

[Folke]

Please take a look at the plural rule for Arabic text then you will
understand the reason for textual aliases.
http://code.google.com/p/google-web-toolkit/source/browse/releases/1.5/user/src/com/google/gwt/i18n/client/impl/plurals/DefaultRule_ar.java

So, we're almost back to aliases.

While I agree with you that there should be a way to override a plural
form by number, I also think that the default implementation shouldn't
force most people to define redundant plural forms, thus the grouping
of "zero" and "other".

I would prefer a combination of both, aliases for grouped selections
and direct selection by number, where numbers override any aliased
selection.

# English

resultsCount = Found {0} results

resultsCount[0] = No results found # overrides "other"

resultsCount[1] = Found 1 result

# Arabic
resultsCount = ...
resultsCount[0] = ...
resultsCount[1] = ...
resultsCount[2] = ...
resultsCount[few] = ...
resultsCount[many] = ...
resultsCount[10] = ... # overrides "few"

The order in which a @PluralCount of 10 is resolved in Arabic:
1. resultsCount[10]
2. resultsCount[few]
3. resultsCount


Thoughts?

[Matt Bishop]

Aliases make sense as locale-specific concepts. If a properties-file
writer (not the same person as the developer in almost every
professional case) wants to utilize them, they should be able to just
call them out.

resultsCount[few] = A few results

However, I think this use case is a bit edgy. For simplicity, the
default behavior would be to just do the number-based system:

public String shots(@PluralText int count)
shots = {0}-shot espresso
shots[0] = Steamed milk?
shots[1] = Single espresso
shots[2] = Double espresso
shots[3] = Triple espresso
shots[4] = Quad me baby!

If someone wanted to use aliases, they could call them out in the
property file:

myMsgs_ar.prop:

shots = {0}-shot espresso
shots[0] = Steamed milk?
shots[1] = Single espresso
shots[2] = Double espresso
shots[3] = Triple espresso
shots[4] = Quad me baby!

shots[few] = Turkish coffee
shots[many] = Way too strong for anyone

If I passed in 3, or 4, I would get the [3] and [4] specific message.
If I passed in 5, I would get Turkish coffee. If I passed in 100, I
would get the 'many' message.

So Aliases would be defined by the locale and used after the specific
callouts were examined. You don't get to define new aliases are
redefine an alias without writing a new DefaultRule.

Finally, I would deprecate @DefaultMessage and
@PluralText. .properties files have been around a long time and have
proven effective. We want to keep those UI strings out of the .java
files and in the hands of trained linguists and grammarians.