Comment by jon-wood
If pluralisation of a status message in the UI is breaking core application logic then you've got bigger problems than the pluralisation code.
If pluralisation of a status message in the UI is breaking core application logic then you've got bigger problems than the pluralisation code.
You'll have to look up the way i18n frameworks work, but no the "(s)" is not worse. It is far better because it's a simple string that the framework can substitute without embedded business logic trying to manipulate the individual characters in a way that only works in one language.
Yeah, I'm with you. I've worked on several i18n frameworks, including ones for AAA game titles at Microsoft.
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.
Huh? "(s)", itself, only works in one language! Other languages (and even English, sometimes) don't always pluralize by appending lettters to the end of words, so the parenthesized suffix thing very regularly doesn't even work.
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.)
Every code path is an opportunity for a bug that escapes validation. Plus this particular example doesn't work with i18n. It would be more complicated in that case.