Plural Rules: Strings That Change with the Number in Software

In English there is a single letter between “1 file deleted” and “5 files deleted”: file and files. That small difference opens one of the most technical topics in software localisation. Plural rules determine how the forms that change with the number are managed in the code.

Contents

If the problem were confined to English it would be easy to solve. Some languages need only one form; others need three separate forms depending on the range the number falls into. Once gender and case endings are added, the table grows wider still. If the code is not ready for this variety, the translation cannot produce the right result either.

Below we set out where the problem comes from, how solutions such as gettext and Plurr work, and why the decision is largely taken at the development stage.

Why are plural rules a localisation problem?

In software strings, numbers are usually carried by placeholders. When the text is written, nobody knows what the number will be. A developer writing in English builds the sentence with a single plural form in mind. That assumption breaks as soon as you step outside the source language.

One layer of the problem is about number, the other about agreement. In a string such as “New %s”, the noun that will go into the placeholder may be singular or plural. In languages where adjectives are inflected, the number of the noun also changes the form of the adjective; a single translation cannot cover every possibility.

The first solution that comes to mind is to write all the forms side by side, separated by slashes. This method is both inefficient and lengthens the string, which causes overflow in the interface. In languages that have a neuter gender the number of options grows further and the solution becomes entirely unusable.

The problem also has a side that concerns word choice. In Japanese the equivalent of “new” changes with the context: general use, the sense of a new model, the sense of the most recent version and the sense of fresh are each covered by a different word. In cases like this the solution comes not from the code but from a context note supplied by the developer.

One adjective, how many forms? A comparison across languages

The English adjective “new” has a single form. In the Romance languages the singular-plural and masculine-feminine distinctions produce four forms. In the Slavic languages and in Modern Greek the neuter form takes the number up to six, and that is the figure reached before grammatical case endings are taken into account.

Language	Number of forms	Example
English	1	new
Spanish	4	nuevo, nueva, nuevos, nuevas
French	4	nouveau, nouvelle, nouveaux, nouvelles
Russian	4 and above	новый, новая, новое, новые
Modern Greek	6	νέος, νέα, νέο, νέοι, νέες, νέα

The table shows how many separate lines a single source string can turn into on the target side. Plural rules are therefore not only a matter of translation quality but also of file size and maintenance cost. Every extra form means one more line that has to be kept up to date.

The Russian example also shows how much the ranges of numbers matter. In this language the ending on a noun differs when the quantity is zero, when it is between two and four, and when it is between five and ten. A single singular-plural distinction does not cover that structure.

Faced with this variety, trying to squeeze every form into one string gets you nowhere. The right approach is to let the code choose different strings according to the number. Each form then stands on its own line, the translator writes each line separately, and only the correct one appears in the interface.

Plural forms in gettext: nplurals and the msgstr array

In the GNU gettext infrastructure the plural is defined at file level. The header of the file carries a line that states the number of forms and the selection formula. This line determines which range of numbers calls up which form, and lets the program pick the right line at run time.

At entry level you see two source fields: msgid carries the singular text, msgid_plural the plural text. The translations are written into numbered fields such as msgstr[0] and msgstr[1]. If the language needs three forms, a third field appears in the file as well.

This structure is clear for the translator, but it has one precondition: the developer must have defined the string as a plural entry. A sentence written as an ordinary text string never opens its plural fields at all. In that case the correction is made in the code, not on the translation side.

The behaviour of the placeholder is different in a plural entry too. On the singular line the number is often given in words, while on the plural line it is carried by a placeholder. This distinction has to be preserved during translation; adding a placeholder to the singular line, or removing one from the plural line, causes the string to break at run time.

Plurr and ICU: a format the translator can read

Plurr is a universal format specification that brings plurals, gender, conditions and placeholders together in a single syntax. It is designed to be easy for the developer to support and clear for the translator to read. A variable is written inside curly brackets, followed by the options separated by vertical bars.

The example given when the specification is introduced is this: a warning that asks whether one file or several files are to be deleted. When the value is one a singular sentence is produced, when it is five a plural one. For Russian the same structure carries three options, because the form of the ending changes with the quantity.

The same specification also works for languages that have no plural form. In Thai a single option is enough. The rule the translator has to follow in these structures is fixed: the variables inside the curly brackets are not touched, only the text of the options is rewritten.

The greatest contribution of specifications of this kind is that they move the plural decision somewhere the translator can see it. In projects where the decision stays buried deep in the code, the translator cannot tell which option will appear when. Once the options are visible on a single line, the text can be read together with its context.

The solution you will meet more often in corporate projects is Unicode’s ICU libraries. Developed for internationalisation, these libraries handle the selection of plural and grammatical gender through a standard routine. All of these approaches rest on the same principle: choosing different strings according to a variable.

Where the rules come from: Unicode CLDR

How many plural forms a given language needs is not settled by guesswork. Unicode’s language plural rules present this information in an orderly form for a large number of languages. These rules cover not only the singular and the plural but also quantity distinctions such as “a few” and “many”.

The CLDR tables serve as a checklist for the development team. Once the languages to be supported have been settled, the number of forms the code has to handle is read off this table. If the decision is taken at the development stage, the translation stage runs without trouble.

Another benefit of the tables is that they prepare you for unexpected languages. A product released today in two languages may open a few years later onto a market with a more complex plural structure. When the code is built to be flexible from the start, adding a new language is a matter of a resource file; when it is not, it becomes a job that goes into the development schedule.

On the mobile side, Apple’s and Android’s own documentation gives similar information, as do the guides of the relevant libraries in games and web frameworks. The common point is this: plural rules are not a translation preference but an architectural requirement.

How do plural errors look on screen?

The most familiar form of a plural error is a noun with the wrong ending next to a number. When users see a warning like “1 items selected”, they conclude that the product has been put together carelessly. The mistake looks like a grammatical one, but its source is usually the code; the string was written on the assumption of a single form.

The second form is options written side by side with slashes and showing up on screen. When the developer or the translator squeezes every possibility into one string, the user is left to read through the options on offer. This method may be a temporary remedy, but it is not a lasting solution.

The third form is the most insidious: the zero case. Many interfaces make no provision for a separate text when the result is zero, and produce a sentence such as “0 results found”. Adding threshold values such as zero, one, two, five and eleven to the test plan makes every one of these errors visible.

The Türkiye context

As far as the number of plurals goes, Turkish is a fortunate language. When a number is stated, the noun takes no plural ending; “5 dosya” is correct, “5 dosyalar” is wrong. In most projects a single form is therefore enough, and the number of forms in the gettext header can be brought down to one.

The real difficulty lies elsewhere: in the suffix that comes after the number. Between “3 dosyayı sildiniz” and “3 kaydı sildiniz” the vowel harmony of the ending changes. When the noun that will land in the placeholder is unknown, choosing the right ending becomes impossible. In Turkish strings the common way out is therefore to phrase the sentence so that it does not hang on the ending.

Most products developed in Türkiye start with Turkish as their source language. That creates the problem in reverse: a string written in Turkish with a single form finds no plural field at all when it is opened up to English or Russian. Once the decision to export is taken, the code has to be opened up to those fields.

In projects with Turkish as the source language it is therefore more economical to put the plural infrastructure in place before the first foreign language is added. If the infrastructure is ready, adding a new language turns into a matter of a resource file and the interface code stays unchanged.

What does this mean for you?

Plural rules are a subject that does not show up on the translation invoice but does show up on the delivery date. If the code is not ready for plural forms, the wrong result will appear on screen even when the translator writes the right sentence. Most of the decision is taken on the development side; your job is to make sure the question is asked in good time.

1. Settle your target languages and have someone list how many plural forms each of them requires.
2. Have your development team confirm that strings containing numbers are defined as plural entries.
3. Have the number of forms in the resource file header checked against the language.
4. Add on-screen testing with zero, one and large numbers to the delivery plan.
5. Track the suffix agreement problem for Turkish as a separate item.

Talking these items through at the start of the project comes far cheaper than a code change made later on. For scope and timing you can request a quote, or browse the other technical articles in our knowledge centre.

Frequently asked questions

Why are plural rules not the same in every language?

Languages mark number in different ways. Some need only one form, others need three or more depending on the range the number falls into. The code has to be ready for that variety.

How is the plural defined in a gettext file?

The number of forms and the selection formula are stated in the file header. Each entry contains a msgid and a msgid_plural, while the translations are written into numbered fields such as msgstr[0] and msgstr[1].

What is Plurr?

It is a format specification that brings plurals, gender, conditions and placeholders together in a single syntax. It is designed to be easy for the developer to support and relatively clear for the translator to read.

How many plural forms does Turkish need?

Turkish generally works with a single form; when a number is stated, the noun takes no plural ending. The real difficulty is not the number of plural forms but the vowel harmony of the ending that comes after the number.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 156–160.
• Unicode CLDR, “Language Plural Rules” tables, unicode.org (online document).
• Plurr format specification, loctools/plurr repository, GitHub (online document).