Plural Formula gets ignored for Singular Case for languages where Singular Form is not found in the first index

If anybody shed light on why the conditional check for $this->count == 1 was included, it would be super helpful.

While I can answer your question it is not helpful at all: the code was added in 1831e1b690 and there was an attempt to fix this in #12096: fix bug with plural forms for some languages → -- both were twenty years ago. The fix apparently was not enough. Locale code is ancient.

It seems to me the following simplification can be made as a step forward:

I have updated the MR with suggested changes.

>... precomputing 0-199

@ghost of drupal past, so we have a bug due to what seems to be a performance optimization. Thanks for the issues links which are quite helpful.

---

P.S. It seems like some comment/s are vanishing, like ghost comments! Is it Drupal.Orgs way of keeping discussion between a dead guy and a ghost spooky ¯\_(ツ)_/¯

Don't see an MR. but it should have test coverage when opened please

I am happy to write some test, but would like to clarify few things,

Question A:
Am not sure about core policy regarding test, I think we would need a kernel test for this one, Is that assumption correct?

Question B:
I see testing this is tricky. This refactor touches part which needs locale module to be enabled and configured in a certain way. So should this test be part of Locale Module testing scope? i.e. test be written under namespace Drupal\KernelTests\Core\Locale instead of Drupal\KernelTests\Core\StringTranslation

Yeah, tests fail... here's a slightly better version, with comments:

    $translated_array = explode(PoItem::DELIMITER, $this->translatedString);
    // No need to check plural formulas if only one translation is provided.
    $index = count($translated_array) === 1 ? 0 : $this->getPluralIndex();
    // If the translation is not found, it's guesswork, and the best guess
    // is the most common case where the first plural form is for n = 1 and
    // the second is for everything else. It's not always correct but
    // ¯\_(ツ)_/¯
    $return = $translated_array[$index] ?? $translated_array[$this->count != 1];

This does bring back the faulty assumption but it's delegated to a fallback case where I don't really have a better idea.

@ghost of drupal past,

I am afraid, we are increasing the scope of the fix.

As far as the scope of this bug report is about, it feels removing the hardcoded condition for "$this->count == 1" should be enough. Trying to find a sane default for cases under following scenario should be followed up in a separate issue (or issues),

- Case A: Translation data is corrupted, i.e. Message array doesn't contain the string at a particular index.
- Case B: Translation index formula can be wrong because of using default plural formula for language where it doesn't make sense.
- Case C: Translation index formula can be wrong due to corrupted Plural Form header in the PO file.

The main source of above scenario would be content/configuration done by User. And as pointed out in comment #8, the outcome has too many variations to handle.

As reported in this issue, despite having configured messages and Plural Formula correctly, Drupal Core fails to use the correct index, and hence that needs fixing.

Sure, it might be too much I was trying to optimize but it was just an idea.