Summary:
It's often possible to avoid quantity strings by using quantity-neutral formulations such as "Books: 1". This makes your life and your translators' lives easier, if it's an acceptable style for your application.
I doubt the plurals work well for other languages as many cases are missing.
From my running of lint there are 74 missing quantities and 18 Implied Quantities along with 98 Unused quantities
Missing quantity translation Different languages have different rules for grammatical agreement with quantity. In English, for example, the quantity 1 is a special case. We write "1 book", but for any other quantity we'd write "n books". This distinction between singular and plural is very common, but other languages make finer distinctions. This lint check looks at each translation of a
and makes sure that all the quantity strings considered by the given language are provided by this translation. For example, an English translation must provide a string for quantity="one". Similarly, a Czech translation must provide a string for quantity="few". Issue id: MissingQuantity http://developer.android.com/guide/topics/resources/string-resource.html#Plurals
Implied Quantities Plural strings should generally include a %s or %d formatting argument. In locales like English, the one quantity only applies to a single value, 1, but that's not true everywhere. For example, in Slovene, the one quantity will apply to 1, 101, 201, 301, and so on. Similarly, there are locales where multiple values match the zero and two quantities. In these locales, it is usually an error to have a message which does not include a formatting argument (such as '%d'), since it will not be clear from the grammar what quantity the quantity string is describing. Issue id: ImpliedQuantity http://developer.android.com/guide/topics/resources/string-resource.html#Plurals
Unused quantity translations Android defines a number of different quantity strings, such as zero, one, few and many. However, many languages do not distinguish grammatically between all these different quantities. This lint check looks at the quantity strings defined for each translation and flags any quantity strings that are unused (because the language does not make that quantity distinction, and Android will therefore not look it up). For example, in Chinese, only the other quantity is used, so even if you provide translations for zero and one, these strings will not be returned when getQuantityString() is called, even with 0 or 1. Issue id: UnusedQuantity http://developer.android.com/guide/topics/resources/string-resource.html#Plurals
@macgills How about using something like - book(s)
I am in favor of it but others would need to be as well. @misaochan ?
Requesting @Nikerabbit or @amire80 's input on this.
Thanks for the ping! I'm not sure I understand the question. Does the app already have proper plural support and you want to remove it? If yes, why?
Or maybe the app doesn't have plural support, and you want to change the existing strings so that they would be number-neutral? If yes, can you just add proper plural support instead?
@amire80
From my running of lint there are 74 missing quantities and 18 Implied Quantities along with 98 Unused quantities
The app has plural support but plurals have a lot of issues. Plurals missing that are required, extra plurals in languages that don't need them.
My suggestion is to use number neutral strings and ditch our plurals.
Hello again, been a while.
Why remove plural support instead of improving the strings?
If there are problems in the translations, mark them as fuzzy by appending the string !!FUZZY!! to the beginning of each problematic translation. And where is the plural support documented? Translators at translatewiki are usually most experienced with localizing MediaWiki and its extensions, and if the strings here work differently, this must be documented. I couldn't find documentation about this.
If there are problems with the English strings, fix them! :)
It is not a problem with the english strings (potentially), it is that the generated plurals exist when they shouldn't and don't exist when they should.
The english:
<plurals name="uploads_pending_notification_indicator">
<item quantity="one">%1$d file uploading</item>
<item quantity="other">%1$d files uploading</item>
</plurals>

Here the mistake was made to add a zero rule for English
<plurals name="contributions_subtitle">
<!--zero is not used in english. Category mentioned here for easy reference in future-->
<item quantity="zero">@string/contributions_subtitle_zero</item>
<item quantity="one">(%1$d)</item>
<item quantity="other">(%1$d)</item>
</plurals>
and that caused this issue

It seems like we would have to supply every rule in the english file to get the correct plural for all languages but this would give us unused plurals in many languages.
Ideally we could define an english plural with only one, other and then the translated file would produce a plural with the correct rules for the language. eg Arabic has few many one two zero other, the whole gamut. That is an ideal world though.
Translators at translatewiki are usually most experienced with localizing MediaWiki and its extensions, and if the strings here work differently, this must be documented. I couldn't find documentation about this.
If I can be pointed at the place to add it then I am happy to add documentation on how android plurals work, which will mostly be a regurgitation of the docs
We now have plural validator for Android. Compare for example to Ajapaik which has it enabled:
Can we enable this validator? It won't magically fix existing violations, but it will prevent new ones.
What would the strategy be for fixing our existing plurals?
I can only make them show up in the list of messages needing translation/updating. Translators are required to update those messages appropriately.
Extreme solution would be to remove the problematic translations for these messages.
It is extreme but slightly to where I am leaning. We have 7 plurals and 2 of these should probably not be plurals.
I'll let @misaochan weigh in as it is not a decision to take lightly.
Can we enable this validator? It won't magically fix existing violations, but it will prevent new ones.
This would be great!
I can only make them show up in the list of messages needing translation/updating. Translators are required to update those messages appropriately.
This sounds OK to me, I would prefer it over simply removing the problematic translations.
Plural validator is now enabled and I'm marking bad plural translations for review.
Btw, zero key should not be used in English. It is not the same as number 0 in some languages. See for example Latvian in https://www.unicode.org/cldr/charts/34/supplemental/language_plural_rules.html
Here the mistake was made to add a zero rule for English
I am aware. I should probably make a ticket to get rid of that also our zero string for that is not a quantity string and should not be used
<string name="contributions_subtitle_zero">No uploads yet</string>
A conditional in code should express it I think
I see that this was enabled in translatewiki. It's mostly a good thing, but would it be possible to make some rules optional? For example, in Hebrew "two" and "many" are almost always identical, and something similar is probably true for a lot of other languages.
It probably has to be done on the translatewiki or Extension:Translate side, so pinging @Nikerabbit again.
@amire80 just as input for "translatewiki or Extension:Translate side", lint would still complain at us if it says hebrew should have two/many and the file only has 1 of the rules. This could be dealt with by having ignores in the hebrew files for this issue of MissingQuantity but it would mask all missing quantities then, unless applied to specific translations
If the linter complains about it, it is a bug in the linter. A linter is supposed to complain about likely problems. A missing "two" rule in Hebrew is likely not a problem because the "two" form is only used when talking about hours, days, years, and body parts, and that's about it. If a linter reports about it at all, it's supposed to be in the lowest priority. A linter is not supposed to override common sense :)
Maybe translatewiki could auto-replicate the two and many rules when synching, but that would be an ugly hack. I'd suggest ignoring this linter error, at least for Hebrew. (And again, I suspect that it's also true for some other languages.)
@amire80 As a translator, what would you think of an explicit syntax for aliasing forms, such as {{PLURAL|one=...|two&many=...}}?
@amire80 As a translator, what would you think of an explicit syntax for aliasing forms, such as
{{PLURAL|one=...|two&many=...}}?
Somewhat redundant, but much better than just duplicating everything.
(And if you are doing this, then this should be documented for all the translatewiki projects where it is used.)
Still no solution for 0= (or zero=)? It is NOT plural for example in French (where it can also be often more clearly translated by a negation, like "none" in English rather than a strict numeral with digits, especially more in scripts which don't have a natural digit for zero, such as in Latin language using "nunc").
Please consider the diversity of plural forms documented in CLDR, don't assume English-like rules. Even if there are digits, the number may be marked elsewhere (e.g. in nouns with variant forms of nouns/adjectives/verbs/pronouns, or reduplication of the noun for the plural, but not for zero which use the same form as singular); as well Slavic and Celtic languages typically have more than 2 forms (so they add "two", "paucal/few" to the "singular" and "plural/many"; Slavic languages have complex rules for determining the grammatical number based only on the last few digits and not the complete vnumeric value, so there are an cyclic infinity of alternating value ranges).