Transifex supports plurals for all file formats that support them, such as Android, Apple strings, Apple stringsdict, Gettext, Java, JSON with ICU plurals, Structured JSON, XLIFF, and YAML.

Transifex also supports a part of the ICU MessageFormat under JSON, Structured JSON, Fileless, and Java Properties. If you have content encoded in ICU, you can use one of the above types to import and export it in Transifex.

Also, the most important and frequently used features of ICU can be supported in other file formats in a non-ICU way, such as plurals, context, and developer comments. Depending on the file format you use, you can access some or all of these features.

You can use PO files as an excellent way to work around this. It is one of the most popular file formats for localization, supported by many frameworks. It's pretty powerful, and we have good support for it.

If you want to bring that info straight from the source file, PO files can support context and developer comments. If you have genders in addition to plurals, you can use the context field (msgctxt) to indicate the gender. You can also use the developer comment (#.) to explicitly tell the translator how to translate the string.

Here is an example showing the same source string but using the context to save two different entities in Transifex.

Another way to specify genders is through the key name. Transifex will recognize the words, Male or Female, in a key name and display a label in the editor that shows the gender. For example, if you have the following entries in a PO file:

Then, the following will appear in the Transifex web editor:

This same concept is applied to all file formats with a key-value structure.

Pluralized strings can also be defined in a PO file as follows:

When Transifex encounters a pluralized entry in your file, it'll associate all the plural forms together. This way, Transifex can present the translator with all the forms in the Editor. At the same time, Transifex knows how many plural forms each language has and asks the translator to translate them. Translators can only save their work if they translate all plural forms in the selected language.

As an example, English has two plural forms ("one" and "other"). The source file will have two phrases, one for each plural form. On the other hand, Russian has four plural forms. So, after the translations are done, when you download the file from Transifex, your translation file will look as follows.

Transifex is following ISO Standards and Unicode CLDR data for the supported languages, as you can read in our documentation.

You can also look at the rules we follow for defining the plural forms here.

Here is an idea of how to use the TM with plural-enabled entities.

We love the concept and idea behind ICU. It's a powerful framework when you have very advanced i18n needs. It's also a neat way to store the actual phrases in the engine itself instead of having multiple fields. It is more fluid, dynamic, and easier to work with as a developer.

So why aren't we natively supporting ICU and suggesting workarounds? Here are some of our thoughts on this.

ICU affects a tiny percentage of users and phrases. Very few of our users' phrases are pluralized (e.g., you rarely see plurals in marketing and user-generated content). From those few users, only some need to support male and female versions. And out of those, less than half are willing to put the effort to support it in their code.

ICU is also a pretty complex framework. The phrase itself is no longer plain English but has variables and logic in it. That's a fundamental difference. It's like replacing your house's bricks with a brick that can grow in size with a button. The change affects every single piece of a localization system like Transifex. Some examples are the Translation Memory (serializing entries when updating a TM of billions of entries is no joke!), the word count across the platform, etc.

Finally, as outlined on this page, you can support the most essential ICU features with Transifex, such as plurals.