Three pluralization mistakes that are messing up your code

We recently worked to internationalize the Asana codebase, and we learned a lot about how to write dynamically pluralized text. We’d like to share three common mistakes that you can avoid the next time you need to use pluralization logic in your application.

1 – You forgot to handle irregular pluralization

buggyPluralize(2, “email”);

> “emails”

If your pluralization function just appends an “s” to an input string, then we’ve got bad news for you. Your code is probably telling users that they have “3 boxs” arriving next week, or that they can click a button to “Roll 5 dices”.

You can fix this problem in English by making your pluralization function by always explicitly stating your singular and plural forms:

okayPluralize(3, “box”, “boxes”);

> “boxes”

That’s much better Let’s learn about another mistake.

2 – You thought that one was the only loneliest number

Let’s say you’re internationalizing your code and have a `translate` function, which looks up the translated version of the passed-in string:

You might think that you’re generating the string “0 answers” in French, but you’re actually creating something grammatically incorrect. Unlike English, French uses the singular form for 0! To a French reader, your sentence will look as incorrect as “You got 0 answer right” does in English.

3 – You assumed there were only two plural forms

This is when pluralization gets even more interesting. It turns out, some languages have more than two plural forms. Arabic, Russian, Czech, and Polish all have more than two plural forms. It’s important that your type signature for okayPluralize be able to handle that.Here some interesting pluralization cases which are used in Arabic:

• numbers that end with a number between 3 and 10 (like: 103, 1405, 23409)

• numbers that end with a number between 11 and 99 (like: 1099, 278)

• numbers above 100 ending with 0, 1 or 2 (like: 100, 232, 3001)

We hope that this convinces you to centralize your pluralization logic into a small, correct module instead of sprinkling it throughout your codebase!

You need a system for text

Even if your product is only in English, you can outright prevent a bunch of technical debt by internationalizing your code as soon as it’s developed. Code goes in your codebase, and data goes into your database. So why not have a textbase?If you’re using a framework with built-in support for internationalization, we highly recommend leveraging that support. There are also tons of open-source solutions that you can integrate into your codebase.Internationalization might not be on the short-term roadmap for your project. However, it’s much easier to do it as you develop new code instead rather than trying to build it into a legacy codebase later.