Only the first plural form is used for Slovak and some other languages

[MiroslavR]

Only the first plural form is used for Slovak, Czech and some other languages. Transifex seems to have changed the plural form expressions. Since tinygettext does not actually parse the expressions, just match them against a hardcoded expr→func map (which is horrible), now everything is broken. This comment has not aged well: tinygettext/tinygettext#21 (comment)

Yes, we could update the map, but do we want to do this every time Transifex changes something? The proper solution is an expression parser and luckily, someone has already done the job: tinygettext/tinygettext#23. I think it would be best if that was merged in. Alternatively, we could switch to proper gettext.

[deveee]

For now I would add the new format to tinygettext, because it's trivial to do. I did it for Polish format before: a40fd4c#diff-c2a77f2867ef1598bb0cc19e1393810a

Do you want to add/test yourself?

Expression parser is good for sure, but it should be properly tested. Or it should be safe to use it only as a fallback for unrecognized formats.

[MiroslavR]

Or it should be safe to use it only as a fallback for unrecognized formats.

That's how the linked PR works. It keeps the expr→func map and handles the else case. I have just noticed from your commit message that Transifex apparently broke the Polish plural expression (ugh) so I guess the map is necessary for Polish at least. Is that still the case?

To be fair, the Slovak expression change is also useless as it only added another form for floating point numbers which are not supported by (tiny)gettext (I wonder if there is any i18n system that supports them). But it is a change nonetheless and Transifex could do these kinds of changes at any time.

Do you want to add/test yourself?

Fine, I might get to it later today or tomorrow. I can only test for Slovak, though.

[deveee]

@MiroslavR I fixed most languages in f605835

I only didn't touch Hebrew, because it had 2 forms before and now it has 4 forms. Also Breton had 2 forms and now it has 5, so I can't really check it if it's correct.

And Slovak translations look incorrect, because I see
10 sekund
2 sekund
1 sekundy
Not sure if you want to fix it in transifex, or maybe I can fix Slovak and Czech myself.

And btw. I didn't test, but for Slovak there is
"Plural-Forms: nplurals=4; plural=(n % 1 == 0 && n == 1 ? 0 : n % 1 == 0 && n >= 2 && n <= 4 ? 1 : n % 1 != 0 ? 2: 3);\n"
while it should be most likely
"Plural-Forms: nplurals=4; plural=(n % 1 == 0 && n == 1 ? 0 : n % 1 == 0 && n >= 2 && n <= 4 ? 1 : n % 1 == 0 ? 2: 3);\n"
Because the 4th form should be used for floating point numbers (it's "other" form on transifes). So that expression parser probably would break it too.

[MiroslavR]

@deveee Are you referring to the string Confirm resolution within %i seconds? If so, the Slovak translation is correct because it's in genitive form.

Regarding the plural expression, Transifex is following CLDR: https://www.unicode.org/cldr/charts/33/supplemental/language_plural_rules.html#sk. I agree that the mapping is unfortunate - it would be clearer if the rules for "many" and "other" were swapped. For Slovak, I have translated both of these as integer "many" (since there is no support for floating point numbers anyway).

BTW, did you deliberately not update the plural3_sk function so that you did the swap on the STK side? Not sure how I feel about going against the plural forms expression, but I guess it won't harm Slovak...

[deveee]

Ok, then Czech will be correct too.

I can't really test without touching translation on transifex, but there are in following order: one, few, many, other. So I suppose that "other" will be 4th form in exported translation and just n % 1 != 0 is incorrect. You can test yourself.

And I just fallback to plural3_sk because STK doesn't support/use plural forms for floating point numbers, so that 4th form doesn't matter.

[deveee]

I just checked and "other" appears as 4th form:

#. I18N: In the 'confirm resolution' dialog, that's shown when switching
#. resoluton
#: src/states_screens/dialogs/confirm_resolution_dialog.cpp:85
#, c-format
msgid "Confirm resolution within %i second"
msgid_plural "Confirm resolution within %i seconds"
msgstr[0] "Zmenu rozlíšenia potvrďte v priebehu %i sekundy"
msgstr[1] "Zmenu rozlíšenia potvrďte v priebehu %i sekúnd"
msgstr[2] "Zmenu rozlíšenia potvrďte v priebehu %i sekúnd"
msgstr[3] "Zmenu rozlíšenia potvrďte v priebehu %i sekúnd ... TEST"

[MiroslavR]

All I'm saying is that to follow the Plural-Forms definition correctly, plural3_sk would have to return msgstr[3] for the last else case, not msgstr[2]. I know very well that STK doesn't support float plural forms.

Transifex (and CLDR) confusingly considers "many" to be the float form and "other" to be the integer many form. For Slovak it currently doesn't matter much because I chose to translate both of them the same way - as the integer many form. But someone else, a pedantic translator, could have analyzed the expression and given msgstr[2] the float form, as expected by Transifex/CLDR, and expected msgstr[3] to be used for the integer many form. Here is an example translation of {} day / {} days:

Transifex/CLDR rule name	Actual meaning	Index	Translation
one	integer one	0	{} deň
few	integer few	1	{} dni
many	float	2	{} dňa
other	integer many	3	{} dní