Dear developers,

Could we please sort out this once and for all,

so we could carry proper translation for Russian language.

The problem here is that there are 3 modifications in Russian language. Examples below are for the translation of the Topic term.

**A.** 1, 21, 31, 41, 51, 61, … … тема (the suffix is **a**)

**B.** 2, 3, 4, [22, 23, 24], [32, 33, 34], [42, 43, 44]… темы (the suffix is **ы**)

**C.** 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, [25, 26, 27, 28, 29, 30], [35, 36, 37, 38, 39, 40], [45, 46, 47, 48, 49, 50]… тем (**no** suffix)

I have seen in Transifex there are 3 translation options for plurals: one, few and many.

Are they all in use?

If yes, then we probably could assign one -> A, few -> B and many -> C.

However, it will be confusing for translators because one is actually one, while the case A includes all numbers with the last digit = 1 (except 11).

**NB.** If we solve this, it will also apply to Ukrainian language.

**The proper solution could be the following:**

Allow for a custom function to be specified in the translation YML file.

That function should return a key that should be used.

Then we will name keys accordingly for Russian translators, for example:

- 1_or_21
- 2_or_22
- 5_or_55

That will make it very clear for any translator, because all they’ll have to do is to use some %{count} keeping in mind that its possible values are 1 or 21, 2 or 22, and 5 or 55.

We can avoid input of functions by allowing keys to be calculated by simple boolean/mathematical expressions in YML file, for example:

```
plural_keys:
1_or_21: n==1 || (n > 20 && n % 10 == 1)
2_or_22: n == 2 || n == 3 || n == 4 || (n > 20 && (n % 10 == 2 || n % 10 == 3 || n % 10 == 4) )
5_or_55: default
```

This could well solve possible problems with other languages. Especially the number of keys needed and the intuitiveness of their names. Just define your language-dependent keys and use them through translation. It seems as boolean+math definitions are more than enough to describe any possible case.

I am also aware of the post below, and some cases in that thread would greatly become much simpler with what I proposed above.