Weblate removes _zero postfixed keys from translation files that were touched

[zakharchenkoAndrii]

Describe the issue

Hi! The issue already was described here as a comment

Preconditions:

• i18next 22.3.0
• weblate server version is 4.17-2

I already tried

• [X] I've read and searched the documentation.
• [X] I've searched for similar issues in this repository.

Steps to reproduce the behavior

Have keys with _zero postfix

1. Go to weblate
2. Change any translation entry
3. Observe that along with original intended change, all keys with _zero has been removed

Expected behavior

Keys are not removed

Screenshots

No response

Exception traceback

No response

How do you run Weblate?

Docker container

Weblate versions

4.17-2

Weblate deploy checks

No response

Additional context

No response

[nijel]

The file handling is done by https://github.com/translate/translate, so if something needs to be changed, it has to be done there.

How does this actually work in i18next? The current assumption is that it follows CLDR plural rules like anybody else. So, these _zero suffixes would not be used if there are no matching CLDR plural for given language.

[zakharchenkoAndrii]

The current assumption is that it follows CLDR plural rules like anybody else

well... probably not.

CLDR plural rule says that English doesn't have zero. However, our case which we are handling and is supported both by i18next & i18n-js is like this:

item_one: "{{count}} item",
item_other: "{{count}} items",
item_zero: "No items" // without this, it would obviously fallback to "_others"

with using i18n-js we didn't have a problem as it was nested object construction and probably was just mapped by Weblate as separate translation keys:

item: {
 one: ...,
 other: ...,
 zero: ...
}

[zakharchenkoAndrii]

I mean... even though we are not doing it by standard, why it removes keys completely?

why not just keeping keys as it is, and treat them as separate translation values on the dashboard...

[nijel]

Because it was the easiest way to implement :-). Doing what you describe involves some corner cases. Possible solutions:

• Introducing different plural rules which would include zero in all cases. Weblate already does this for Stringsdict where it is mandated by the format. But this makes the decision on the translation, not on the string level.
• Handling _zero suffixes as separate strings when present in the source language. That would require additional logic to skip such strings for languages which have zero rule included.

[zakharchenkoAndrii]

The first option sounds more reasonable 🤔 . The Second one kind of ambiguous and can confuse users

[github-actions[bot]]

This issue has been added to the backlog. It is not scheduled on the Weblate roadmap, but it eventually might be implemented.

In case you need this feature soon, please consider helping or push it by funding the development.

[nijel]

A similar situation is with Rails Internationalization (I18n) API, it can have optional zero plural as well, see https://guides.rubyonrails.org/i18n.html#pluralization.

[nijel]

This feature of i18next was introduced in https://github.com/i18next/i18next/releases/tag/v21.6.0

[zakharchenkoAndrii]

This feature of i18next was introduced in https://github.com/i18next/i18next/releases/tag/v21.6.0

yes, and we are using this feature for more natural localization. That's, probably, why we have this problem. (our i18next version is 22.3.0)

[nijel]

I think we will go the same way as with Apple StringsDict and always include zero form for these two formats. It just needs coordinated changes in Weblate and translate-toolkit.

[ahus1]

I'm new to Weblate and I stumbled across this issue when handling our i18next v4 files. For one of the files I've chosen by accident the v3 version, which uses numeric suffixes instead. Once I did that, Weblate treated them as separate keys.

So the workaround for me would be to use i18next v3 (or plain nested JSON) as long as my languages have the same suffix? Do I happen to miss some problem lurking here?

[yarons]

Is there an open PR in translate-toolkit we can follow?