i18next v3
The i18next v3 plural format
For a decade of i18next, a plural was two keys: the base for singular and
key_plural for everything else. Languages that
refuse to fit two forms got numbered suffixes (key_0,
key_1, key_2) mapped to the locale’s plural rule,
which worked, and which nobody could read without the rule table open.
This page covers the convention, its history, why the numbered suffixes were the weak point, and what the v4 format changed.
Examples
Two keys, and the numbered escape hatch
English fits the happy path. Polish shows the era’s weakness: the numbers
are positions in the locale’s rule, not names, so nothing in the file says
item_2 means the many form.
"item": "{{count}} item",
"item_plural": "{{count}} items""item_0": "{{count}} artykuł",
"item_1": "{{count}} artykuły",
"item_2": "{{count}} artykułów"item: "{{count}} item"
item_plural: "{{count}} items"item={{count}} item
item_plural={{count}} itemsHow it works
The library counts, the suffix selects
At runtime i18next mapped the count through the locale’s plural rule to a
suffix: none or _plural for two form languages, an index for the
rest. The file itself carries no hint of the mapping, so the same
_2 suffix means different things in different languages, and a
translator working outside the library’s docs is guessing.
Origin
Where it came from
i18next appeared in 2011 and grew into the most used JavaScript i18n library;
this plural convention is simply its classic JSON format, from before
Intl.PluralRules existed in browsers. Once browsers could name
CLDR categories natively, the numbered workaround had no reason to live, and
the v4 format replaced positions with
category names in 2021.
Trade offs
Strengths and limits
Trivial for two form languages
English, German, Dutch: one extra key and done, readable by anyone.
Numbers are not names
The multi form suffixes are rule positions; without the rule table the file is unreadable.
Superseded
v4 fixed the naming in 2021; new projects should not adopt v3, and this page exists because old files do not migrate themselves.
In locamorph
How locamorph treats i18next v3
The i18next plural format on export writes the base and _plural
pair, which is all the convention can label. Suffix keys in imported files
arrive as ordinary separate keys; for a labeled multi form encoding, use
v4 suffixes or
ICU.
Further reading
- i18next JSON format history, v1 through v4
- CLDR plural rules, what the numbers secretly meant
Related
Keep going
Old files, modern plurals
Bring v3 era files in as they are, translate with named forms, and export the convention your current stack expects.