i18next uses suffixes for plural forms, and always supports the _zero suffix.
From i18next documentation
We provide the ability to have special translation for {count: 0}, so that a more natural language can be used. If the count is 0, and a _zero entry is present, then it will be used instead of the language plural suffix.
When using JSON i18next files in Crowdin, the only workaround I found to support these _zero entries is to create custom languages. However this doesn’t quite work as the _zero form from the source file won’t be displayed, and it doesn’t look like a custom language can be used for the source.
I think _zero should always be an option, regardless of the source/target language.
I’d be happy to try any suggested workaround, but from my point of view this is a bug/missing feature of the file format support.
+1 we have to create custom target languages to have the _zero plural form. would be nice if this was configurable at the language level, just like we can map locales strings
As for now adding new forms to the French language is not on our road map as it may cause significant changes to the workflows of our customers that are using old libraries. Hope this will be re-consideres in the future. Meanwhile please use the workaround with a custom langauge.
The custom workaround I described above is incomplete, as the source language will not display the Zero form. Is there a way to use a custom language for the source?
I think there is no need to change the default of how French should work, but I think it would be very useful to adjust the pluralisation settings of a language, or allow us to configure a language to always include support for zero, either through the zero or _zero plural forms.
So, we found that the ICO message format actually can support this out of the box.
Say we have the following base value:
{count, plural, one { one person } other { # people }
For French we can do the following:
{count, plural, =0 { aucune personne } one { une personne } other { # personnes }
This works both in the crowdin interface, and seems to work with our in app ICU implementation as well. This also works for any random value, so you could make special rules for 42, 13… any number you want!
So @Olena disregard my previous message, we found a solution that just works.
I can’t find a way to add countBack_many to it without adding it to en
Even if I upload translated it file with that additional string, it doesn’t show up
Thanks! I checked your project in our database, and it seems that your files were uploaded as Generic JSON, which does not support pluralizations. In order to have the i18next JSON files in your project, you are welcome to upload your sources via CLI or API, where specifying the needed type: i18next_json.
I’m definitely not implementing API support for such a small project like mine, but I checked the CLI. I don’t see type option in the linked doc. Which one would it be?
I just tried to implement it with IntelliJ IDE and got this:
Error from server: Code: 403, Message: This action is not available for the account subscription plan
So I checked the plans and I guess I could use CLI, but I’d need 4 branches support, so the price skyrockets to €151/mo, which is insane for my personal side project. I think I’ll try to implement CLI workflow and deal with different branches manually
Glad to see it’s being taken care of, but I already have another self-hosted solution running with a DeepL free plan. Actually, while setting it up and uploading/translating my locale files, I noticed that Crowdin also messed up a couple more strings, which I could spot immediately. Although it was a really minor issue, but still. Sorry, I won’t be able to find what it was now.
In any case, thanks for your kind and reasonably quick answers
Depending on your file format, there may be a need to adjust a different SRX rule to have a needed segmentation, maybe this can be an explanation of what messed up your strings.
Anyway, if there’s anything else we can do for you - let me know