You can make pluralization work but the "(s)" is going to tend to work better.
And localization isn't just an opportunity for development bugs, localizers get things wrong too. Some non-English speakers mentioned to me that some translations are so bad, it's better to use the English version anyways.
And who exactly is talking about "embedding" business logic in the i18n framework? Every serious framework I've used has supported placeholders, so at the application level you just select between singular and plural form and then the translation framework can handle arranging the words.
e.g. `items.length == 1 ? _t("%d item", items.length) : _t("%d items", items.length)` and then within your translation files you can specify translations that rearrange the phrase, like "<noun> %d" for languages where they are reversed.
(though usually of course, you would use much longer phrases, so that the translation is done in-context.)
That doesn't prevent a good translation framework from working properly, but it proves why the sample code in your example & the OP would not work.
https://www.unicode.org/cldr/charts/43/supplemental/language...
No, wait.
These days many i18n frameworks do need to embed some business logic, even if it is mostly fun things like the CLDR plural categories: https://www.unicode.org/cldr/charts/48/supplemental/language...
Mozilla's Fluent, for example is designed for maximal i18n support of plural selectors and other such things i18n needs: https://projectfluent.org/