Plural localization for negative number does not apply CLDR plural rules

[axunonb]

Discussed in #497

Related: PluralLocalizationFormatter

^{Originally posted by karljj1 October 2, 2025}
Hi,

I have noticed that if we use a negative value in a plural, the behaviour is different.
For example, -1 will produce a different result than 1 when using the English plural:

I have {0:plural:{} apple|{} apples}

1 = I have 1 apple
-1 = I have -1 apples

Are there situations where a negative plural will be different, or should we Math.Abs them before we evaluate the plural?

[axunonb]

The current implementation of PluralRules applies only a subset of the pluralization logic defined in CLDR plural rules.

Notably, while CLDR evaluates the absolute value of a number to determine the correct plural category, PluralRules does not. Instead, it implicitly assumes positive input values — except for two cases where negative numbers are handled, albeit incorrectly. As a result, negative numbers typically fall back to the OTHER category.

Additionally, for certain locales, the resolved plural form depends on the number of plural word variants provided to PluralLocalizationFormatter. In your example, DualOneOther receives two plural forms along with a negative number, which incorrectly resolves to the wrong plural category.

This behavior could reasonably be considered a bug. However, addressing it would require changes to pluralization logic for several locales.

@karljj1 Given these issues, should we consider deprecating the current implementation? Unfortunately, PluralLocalizationFormatter is bundled with the core SmartFormat package, which complicates versioning and migration. What would be a good strategy? Publish a separate package that also takes #499 into account?

[karljj1]

I saw that you've made some changes for this. Thanks!
Whilst porting them over to our version, I noticed a possible issue in the DualOneOther handling. It currently checks n < 0 ? 0, which will no longer work. In the version we have, there is a test which detects this:

[Test]
public void PluralNumber_NegativeZeroOneOrDefault_ValueNegative2()
{
    var formatString = "{0:p:negative items|no item|one item|many items}";
    var expectedOutput = "negative items";

    string actualOutput = m_Smart.Format(formatString, -2);
    Assert.AreEqual(expectedOutput, actualOutput);
}

Is this new behaviour correct, or do we need to preserve the negative value when using DualOneOther?

[axunonb]

Yes, I became aware of this behavior and modified the unit tests that explicitly checked for negative values. The behavior was only implemented in some of the delegates - probably without becoming aware of breaking the plural rule logic. This must have happened close to version 1.2.
Please see my comment here.

[karljj1]

Yes, I became aware of this behavior and modified the unit tests that explicitly checked for negative values. The behavior was only implemented in some of the delegates - probably without becoming aware of breaking the plural rule logic. This must have happened close to version 1.2. Please see my comment here.

Oh, yes, sorry, I forgot you mentioned it. Its not something we have documented. I think ill change our version so it uses Abs for all cases except 4. We can remove the support when we upgrade Smart format.
Im not sure this requires a new package, though. We could keep the old delegate and replace it with a new version. Then if users need the old behaviour, they can call some method to apply the old delegate back.

[axunonb]

We could keep the old delegate and replace it with a new version

This is an option. In this case, however, the new version should opt-in to use the CldrPluralRules instead of the current partial implementation in PluralRules.

This outlines the implementation I have in mind:

enum PluralCategory
{
    Zero,     One,     Two,     Few,     Many,     Other
}

Few and Many are special cases that are grammatically the same as Other, meaning the plural form.

Example for French:

Number	CLDR Category	Full Phrase in Context
$1$	one	1 jour (1 day)
$2$	other	2 jours (2 days)
$1,000,000$	many	1 000 000 de jours (1 million of days)
$1,000,001$	other	1 000 001 jours (1,000,001 days)

The number of plural form arguments to PluralLocalizationFormatter must always match

• either the exact number that CldrPluralRules uses for a locale
• or the number except Few and Many as an acceptable simplification.

Only the absolute decimal value will be used for evaluation of the plural form.

In order to further ease localization, the PluralLocalizationFormatter should be modified, to that it can process localized string values from (child) LocalizationFormatter including the {} placeholder. E.g.:
English/Neural: {} item|{} items
French (simplified version): {} élément|{} éléments

Usage:
"{0:plural:{:L:{} items|{} items}}" should e.g. reult in "200 éléments" or "0 élément"

What do you think?