Comment by jordanb
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.
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.
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.)
Your example is still hard-coding just the two plural categories of English "one" and "other".
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/
Many languages have very complicated pluralization rules. For example, Russian has different plural forms for numbers ending in 2.
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...
The (s) alternative that the article is arguing against is even worse for i18n, so what's your point?