Incorrect number of results reported

Jump to: navigation, search
Screenshot of new translation page as of today with contradictive messages.
We are shown "one result found after filtering" (in the yellow box) even if there are no results, as the new translation page shows just below that yellow box: "There is nothing to be translated", see attached screenshot,
20:50, 30 March 2013

It works for me in Dutch and English. I'll look into the "ksh" translation potentially being faulty, or otherwise the plural handling in JavaScript.

08:36, 1 April 2013

The problem is indeed in the translation:

{{PLURAL:$1|Eine|$1|keine}} Träffer för „$2“

Should be:

{{PLURAL:$1|keine|Eine|$1}} Träffer för „$2“

Reason for this is the order of the definitions for plural forms in languages/data/plurals.xml:

        <pluralRules locales="ksh">
            <pluralRule count="zero">n is 0</pluralRule>
            <pluralRule count="one">n is 1</pluralRule>
08:49, 1 April 2013

In MediaWiki, the order of parameters of PLURAL for ksh is:

{{PLURAL:$n | $n is one | $n is not zero and not one | $n is zero }}

for historical reasons. Since we can hardly tell MediaWiki processed message from JavaScript processed messages, having incompatible parameter orders is quite undesirable.

In additon to the historical reasons and several hundreds of message using it already, the paramter order as of MediaWiki is the better choice for leaving parameters out. The (n=zero) case is more often identical to ((n != one) and (n != zero)), but (n=one) is hardly ever identical to ((n != one) and (n != zero)).

Conclusion: I suggest to alter languages/data/plurals.xml - would the following be correct? There is some guesswork in it from my side:

        <pluralRules locales="ksh">
            <pluralRule count="one">n is 1</pluralRule>
            <pluralRule count="nonzero">n is not 0</pluralRule>
00:04, 4 April 2013

The above quoted data is from CLDR. We will not override it.

00:08, 4 April 2013

Does that mean, I should change it at CLDR? That is of course possible, but will take ages until we have it here. When I submitted ksh plural definitons to CLDR, they did not have any documentation or hints on the fact that the order of cases was relevant, or even useable/used elsewhere.

As far as I know, the feature that values can be left out from the right, which TWN even enforces since not too long, is not part of the plural handling of CLDR, or at least was not, when the ksh plural rules were submitted.

Other translation platforms using the CLDR plural definitions, let translators choose the order in which they specify cases.

Does the JavaScript implementation of PLURAL support the keyword version of parameters? If so, using keywords might be a good temporary fix until a general solution is found and working,

00:26, 4 April 2013

Using a different order for plural forms than CLDR is not an option here. We are trying to make our plural rule support more and more standard compliant. I understand that there can be messages where zero form is written at the end of all forms like

{{PLURAL:$n | $n is one | $n is not zero and not one | $n is zero }}

As per MW implementation of CLDR rules, this must be

{{PLURAL:$n | $n is zero | $n is one | $n is not zero and not one}}

Also, instead of random order of plural forms, it is logical to use plural forms in the increasing order of $n

In addition to the above syntax, it is always possible to explicit rules like

Box has {{PLURAL:$1|one egg|$1 eggs|0=no eggs}}.

The above message will get rendered like below when $1 is 0

Box has no eggs.

More documentation on explicit plural forms:

Having said that, this change has implication on the existing messages of ksh using the zero form at the end. We probably need to mark those messages fuzzy.

05:52, 4 April 2013

Please do not fuzzy. Any solution will be bot-driven. Fuzzying will thus be unnecessary, whatever the final solution will be.

I gave the version with explicit numbers a series of tries. It is not working.

Having incompatible PLURAL syntax inside the MediaWiki: namespace for different messages or message groups is imho not acceptable, and too error prone anyways.

21:59, 14 April 2013

This thread is created nearly 4 years ago, and is this issue fixed in the past years? If not, would asking at Phabricator be a good idea?

13:01, 14 May 2017