At the moment PluralFormula doesn't filter or validate the input from a .po file.
If someone accidentally copies the .pot template to a .po file the Plural-Forms will be invalid:
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"
In turn this will cause a bug on the "User interface translation" overview:

Another side-effect will be that PluralFormula::loadFormulae stores the faulty plural definition "INTEGER" in a State variable:
$ drush state-get locale.translation.formulae
array(1) {
["locale.translation.formulae"]=>
array(3) {
["nl"]=>
array(2) {
["plurals"]=>
string(7) "INTEGER"
["formula"]=>
array(1) {
["default"]=>
int(0)
}
}
In turn, this results in a bug where plurals no longer work because PluralTranslatableMarkup::getPluralIndex will always return the singular string:

Comments
Comment #2
mpp commentedComment #3
mpp commentedComment #4
andypostneeds wrap at 80 chars
Comment #5
mpp commentedWrapped the comment. Do we also wrap if() statements?
I should probably also use ctype_digit instead of is_int.
Comment #8
andypostNo reason to wrap "if" here
Meanwhile failed tests means this condition needs BC shim
Comment #9
mpp commentedTesting with
ctype_digitas the number is probably formatted as a string.Comment #10
mpp commentedPerhaps it would be better to throw an Exception if the plural information is invalid?
Comment #11
mpp commentedComment #20
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
This will need a test case to show the issue.
Did not test for issue btw.
Comment #23
gábor hojtsy