Incorrect number of results reported

Incorrect number of results reported


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,

Purodha Blissenbach (talk)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.

Siebrand08: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>
Siebrand08: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>
Purodha Blissenbach (talk)00:04, 4 April 2013

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

Siebrand00: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,

Purodha Blissenbach (talk)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.

Santhosh.thottingal (talk)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.

Purodha Blissenbach (talk)21:59, 14 April 2013

There's a single PLURAL syntax for MediaWiki, however there are different plural rules. This is the problem because rules are fixing the number and order of items in the MediaWiki PLURAL syntax

The good thing to do for MediaWiki would be for PLURAL to NOT require the implicit' numbering for items, but allow them to be explicitly given by a "|selector=text" parameter instead of just "|text"; i.e. the Mediawiki PLURAL syntax for its parameters should work exactly like template parameters (that also have implicit numbered names for unnamed parameters)

In that case, PLURAL could allow standard CLDR selectors everywhere (they can be named "zero=", "one", "two", "few", "many", etc., but can also be optional specific numeric values like "0=", "1=", "2=")

  • all parameters without selectors are mapped to CLDR selectors according to their order of appearance in the function call
  • selectors can appear in *any* order in the PLURAL function call
  • selectors used by each parameter have to be unique, after mapping their aliases
  • numeric values "0=", "1=", "2=" are always treated treated as aliases for "zero=", "one=", and "two=", where they exist in CLDR rules for the language, meaning that if you use "0=" and "zero=" in the function call they are in conflict, and should resolve to use the named value "zero=" and "0=" is not used
  • The problem with Ripuarain/Kölsch is that CLDR rules where specified by placing "zero" to the 1st position so the 1st unnamed parameter maps to the value "0=" and not "1=": for this to work successfully, this means that parameters given to the PLURAL function without an explicit selector MUST not be mapped by a simple numbering from 1 to n (except the last parameter without explicit selector which MUST map to "many") but to CLDR names in the same order as they occur in CLDR rules, so for Kölsch they will map to ("zero","one","two","few",..., "many") in that order, and not ("one","two","few",..."many") as in most other languages
  • mapping a value for "zero", "one" or "two" must be allowed in all languages even if they don't have this rule specified in CLDR (in that case they must be treated as selecting the numbers "0", "1", "2" as optional overrides for the usual plural forms defined in CLDR for the language)
  • as well "many" must be accepted in ALL languages, it is not a numeric override but acts as the default and it is the "many=" selector which is to be always used in the PLURAL function call parameters for always mapping the last unnamed parameter.
  • You cannot use an explicit "many=" parameter at the same time as the last parameter set without a selector: {{PLURAL:...|many=texts1|texts2}} creates a conflict. The rule is to apply the same logic as in Mediawiki: the last mapped value overrides the previous mapped value for the parameter with the same name, so "text2" would be returned and "many=" would be ignored; but in {{PLURAL:...|texts2|many=texts1}} this would be exactly the opposite.
  • In summary, the PLURAL MediaWiki function only offers the possibility to set parameters without naming them only as a shortcut facility (just like with templates); in all cases unnamed parameters are processed to assign them a name, and other explicitly numbered parameter names come as overrides except 0, 1, 2 which map instantly to "zero", "one", "two" when they exist in CLDR rules; if a named parameter is set with he names "zero", "one", "two" and these do'nt exist in CLDR rules for the language, they must be treated as if they were numeric overrides and are remaped to "0", "1", "2" explicitly.
  • Then the list of parameters can be built as a normal dictionnary mapping containing (key,text) pairs; the actual source list of parameters is processed normally from left to right to assign keys in that dictionnary
  • Then PLURAL will process these parameters: if a language specifies some CLDR rules needing some form like "one", it will default to the value assigned to the "many" key.
  • Note that the preprocessed dictionnary of (key,text) values will always contain the key "many" (because it is required on all languages, and it is also the key used for the last unnamed parameter in ALL parameter lists that are given in the syntax of the PLURAL function call. If there's no parameter given to "many=" or if there's no unnamed parameter, then it takes the default value "", an empty string.
  • This way we become fully independant in Mediawiki about the number and order of rules defined in CLDR, we preserve the facility of specifying the various plrural forms in a specific order without nameing them explicitly; but we can control how they will be mapped.
  • Rules defined for languages may specify how their CDLR-based rules will fallback to one rule to another (not necessrily first to the "many" rule).

So for Ripuarian/Kölsch the translation above should be (or should become) any one of:

  • {{PLURAL$1|nichts|$1}} (not recommended, but preserved for compatiblity)
  • {{PLURAL$1|0=nichts|$1}}
  • {{PLURAL$1|zero=nichts|$1}}
  • {{PLURAL$1|many=$1|zero=nichts}}
  • {{PLURAL$1|$1|0=nichts}} (not recommended, but preserved for compatiblity)
  • {{PLURAL$1|$1|zero=nichts}} (not recommended, but preserved for compatiblity)
  • ...

(all of them equivalent with the rules above and without any conflicting mapping)

And if there are any ambiguity for translators, they can (and should) use explictly named parameters (the 1st form above is preserved for compatiblity, but not recommended as it implies that translators are aware of which CLDR ules are used, and about their order of definition). Only the LAST unnamed parameter (given without an explicit selector) can have its implicit name "many=" omitted (including in the last two examples just above).

Verdy p (talk)09:23, 10 June 2022

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?

Liuxinyu970226 (talk)13:01, 14 May 2017