I18next / custom language ordinal support

Crowdin Issues
1

Ordinal plural support seems to be incomplete in multiple areas of Crowdin.

  • First, it doesn’t seem to be recognized by the i18next plugin. Keys containing _ordinal_ should be using the ordinal plural options, but a translation to en_US only shows one/other as the plural forms.
  • Second, when creating a custom language (our only option to work around other Crowdin limitations with i18next), there is no option to select the ordinal plural form.

This and the previous issue makes Crowdin support for i18next very limited once you go past the most simple use cases.

Is there a workaround to support ordinal plurals with i18next?

2

Hello Matthieu,

Thank you for bringing this to our attention. I don’t see any projects under your account, is there a chance you can share the link to the one you’re working on and experience this limitation?

Alternatively, some sample files would be appreciated. For example, i18next JSON supports pluralization in the following way:

Regarding the creation of a custom language, the absence of an option to select ordinal plural forms is noted. While we do not have an immediate workaround for full ordinal plural support with i18next, our team is continuously working on improving our services and features.

3

Hi Dima,

Thanks for the quick response,

Here’s the project link: Crowdin . We’re under the free plan and using a shared login, hence why it’s not under my own account.

Our source language is en (effectively en-CA) and one of our target languages is a custom version of en (en-US)
an example source JSON would look like this:

{
  "birthday_ordinal_one": "{{count}}st Birthday",
  "birthday_ordinal_two": "{{count}}nd Birthday",
  "birthday_ordinal_few": "{{count}}rd Birthday",
  "birthday_ordinal_other": "{{count}}th Birthday",
}

Without translating anything, the github integration attempts to push the following to our repository:

{
  "birthday_ordinal_zero": "{{count}}th Birthday",
  "birthday_ordinal_one": "{{count}}st Birthday",
  "birthday_ordinal_other": "{{count}}th Birthday",
}

The _zero key is generated because we’re using a custom language for the workaround mentioned above. It’s unnecessary, but no big deal.

Not having the _two and _few keys means i18next will get the key from our default language. At the moment it’s okay-ish, as we’re falling back from US to Canadian English, but this can be an issue for other languages and is definitely a tricky thing to remember for long-term maintenance of our application.

4

Dear Matthieu, could you please kindly try to set the Export option to Skip untranslated strings? That will help with the export, so you will be able to insert the correct translation to the _two and _few keys and until you do it, those strings won’t be sent to your repo

5

Hi Natalia,

From what I’ve experienced “Skip untranslated strings” results in JSON entries with empty strings being exported for anything that isn’t translated, rather than omitting the JSON entry.
This means that no text will be displayed unless it’s explicitly translated, which isn’t a good option for us.

6

Hi @matthieu.foucault !

Sorry for the confusion! Once the “Skip untranslated strings” export option is enabled, the untranslated strings in i18next JSON file will be pushed with empty values. This information is indicated in our article:

In this case, you may try to enable “Skip untranslated files” option and the files that aren’t fully translated will not be exported.

Thanks,