Mark key as translated if it has translation for at least one derived key

[bratzie]

Is your feature related to a specific framework or general for this extension General

Is your feature request related to a problem? Please describe. After adding a russian with more than 2 plural forms, all of my languages will display missing keys, as the syntax for languages that use _plural and languages that use _0, _1. _2 (and so on) differ. All my "normal" languages will say that they are missing keys like {key}_0. The multiple plural form languages will say that they are missing _plural forms.

Describe the solution you'd like I feel like the framework knows which languages have certain settings, so I guess it would be cool there was a setting where languages utilizing _plural would ignore keys with _{number} (and vice versa) in order to see if a language is 100% covered.

Additional context In the following screenshot, you see the all languages at around 90%, since they are complaining about missing keys not applicable for their language.

Worth noting is that we noticed this when we started using Lokalise. We had been (wrongfully) using the _plural syntax for Russian earlier. But files downloaded are correctly formatted for the appropriate language, leading to the above situation which doesn't look good in the extension.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[antfu]

@bratzie Sorry for the delay, do you see if we make the derivedKeyRules accept regex would solve the problem for you?

For example:

"i18n-ally.derivedKeyRules": [
  "{key}_plural",
  "{key}_\\d+",
  "{key}_meta_.*"
]

Will make foo_plural, foo_35, foo_meta_anything marked as used as long as the foo is presented?

[bratzie]

I think that proposed solution would solve #552 perfectly! That was about usage reports :)

I don't think that would help in this (#570) case though, Since the keys in the progress tab don't seem to take those rules into account for what it shows. I have {key}_n (n = 0, 1, 2, 3) as rules and they still show up under "No Translation". Hopefully the image makes it clearer.

This issue is rooted in the fact that once you have languages with 2 plural forms (key and key_plural) with other languages using more than 2 plural forms (key_0, key_1, key_2 and so on) you will have a lot of missing keys in either languages that aren't really missing since it's just using a different structure.

In my case, English has key and key_plural (which solves all cases for English, but it's complaining that my English is missing Russian plural forms) and with Russian it's vice-versa. I have the correct plural forms, but it's complaining that I'm missing base-keys and _plural.

Sorry for the delay, I was on vacation 😅

[terales]

Here is a small example based on i18next syntax:

// en.json
{
  "order.positions": "One book was ordered",
  "order.positions_plural": "{{count}}  books was ordered",
}

// ru.json
{
  "order.positions_1": "Одна книга заказана",
  "order.positions_3": "{{count}} книги заказаны",
  "order.positions_4": "{{count}} книг заказаны",
  "order.positions_5": "{{count}} книг заказаны"
}

@bratzie Did I get it right that it's expected that the extension would:

1. not complain about an order.positions key if there is at least one occurrence of such key or derived key,
2. and not complain about differences in the derived keys between languages?

[bratzie]

That is how I would expect it. I would expect the extension to understand that a language has either the double plural (en.json) or multiple plural (ru.json) and consider both of those occurrences as fulfilling "having the key". If those were the only keys, I would expect it to show 100% on both the en locale and the ru locale as you have 100% coverage of the keys.

So 1) yes, and 2) yes

But I guess it's special in this case. If I had a the following key "order.positions_empty": "Nothing was ordered" (which is not plural) in my en.json I would expect it to complain if that was missing in my ru.json file. So it is mainly an issue with plural forms, as those are expected to be different between languages with different plural rules.

[terales]

It's hard to imagine what kind of configuration would be enough to support different formats. Do you have any ideas of possible solutions?

[bratzie]

Maybe being able to configure number of plural forms per language? Either adding settings in the app, or providing a file that the addon reads? Maybe something like en: 2, ru: 4 and it would deduce what structure the language would have depending on that number? I think Arabic might have 6... 😅 I'm not sure if this is explicitly an i18next problem as I'm not super familiar with how other frameworks structure keys like that. If it's 2, expect keys in the _plural form, and if it's >2 expect keys in _n (n=0...5) form.

https://unicode-org.github.io/cldr-staging/charts/37/supplemental/language_plural_rules.html is a great resource.

[terales]

Frankly, I feel reluctant about adding a specific config just for i18next custom approach to plurals.

The standard way is to use ICU plural format within one key: https://unicode-org.github.io/icu/userguide/format_parse/messages/#complex-argument-types

It's supported by:

• react-intl https://formatjs.io/docs/intl-messageformat#message-syntax
• lingui.js https://lingui.js.org/guides/plurals.html
• many backend libraries.

But i18next and vue-i18n have their own and different implementations 🤷‍♂️

---

i18n Ally could avoid dealing with plurals as soon as the standard ICU syntax is used (one key = one message with multiple options according to plural rules) or with vue-i18n (still, it's one key = one message with multiple options).

But i18next particular implementation brings a lot of additional complexity.

A much simpler implementation would be to just not reporting missing translations if at least one of forms exists according to the derivedKeyRules and shift the responsibility of plural form validation to the localization platforms.

@bratzie would it solve the issue of seeing reports with missing translations for you?

[bratzie]

I agree, it feels like implementing something complex just to solve this specific issue seems a bit overkill.

I think your proposed simpler implementation would solve it for my use case at least :)

[bratzie]

I noticed the new label. Does that mean that you've deprioritized this for the time being? I'll see if I can get some time to figure something out if that's the case.

[terales]

Yep, we were not able to work on it during the latest iteration.

Would love to have helped here, as we would be focused on launching Vue support for JetBrains IDEs during the upcoming weeks.