Plurals in all Polish translations are wrong

[rluzynski]

I hope it's not the worse place to report an issue. The problem is not just in mate-desktop project but in whole MATE. Translations have been recently updated from Transifex and in all Polish translation files (*.po) plural rules have been changed:

-"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"
+"Plural-Forms: nplurals=4; plural=(n==1 ? 0 : (n%10>=2 && n%10<=4) && (n%100<12 || n%100>=14) ? 1 : n!=1 && (n%10>=0 && n%10<=1) || (n%10>=5 && n%10<=9) || (n%100>=12 && n%100<=14) ? 2 : 3);\n"

Actual plural rules for Polish language are:

• one: 1 (that's obvious);
• few: 2, 3, 4, and everything above ending with 2, 3, 4, except 12, 13, 14;
• many: everything else (that means ending with 5..9, 0, 1, and everything between 10..20, also including 0);
• numbers above 100 are treated modulo 100.

There was nothing wrong with the old rules, they didn't have to be changed.

Let's analyze the new rules:

• n==1 ? 0 - this is not changed and correct;
• (n%10>=2 && n%10<=4) && (n%100<12 || n%100>=14) ? 1 - this incorrectly assigns 14 to the rule few; it's a bug and the sufficient reason to reject this change;
• n!=1 && (n%10>=0 && n%10<=1) || (n%10>=5 && n%10<=9) || (n%100>=12 && n%100<=14) ? 2 - uhm, that's so ugly but let's analyze. It was not necessary to check if n!=1 because it's already guaranteed; the next rule trying to determine that the number ends with 0..1 or 5..9 or 12..14 looks correct but it's unnecessary because it's also guaranteed (also, due to the bug, it's guaranteed that no number ends with 14);
• : 3 is unreachable - at least correct but confusing for translators, leading to more incorrect translations;
• these rules define 4 plural forms which is incorrect;
• the rules are long (155 characters!), ugly, unreadable, difficult to debug and analyze, which leads to bugs.

Please update ASAP, before the new release reaches the users' desktops.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[raveit65]

@stefano-k ^^^^^

[monsta]

We don't change any details for a particular language on our side. We only upload po/*.pot file (which contains all the original strings) to Transifex, and from that point it's all done there. We don't edit *.po files manually. We sync them from Transifex from time to time.

Did you report it there first?

[rluzynski]

I understand that Transifex would be the correct place to report the issue. But they don't seem to have a place to report translation problems, no bugzilla nor anything like that. That's why I reported here. Any better idea how to contact the translators? Email them directly?

[monsta]

You can send them messages directly there. The FAQ mentions that:
https://docs.transifex.com/faq/all#collaborating

The Polish team is listed here:
https://www.transifex.com/mate/teams/13566/pl/

[rluzynski]

Thank you, @monsta. I've contacted some people from the Polish translation team at Transifex and got some responses. I really regret there is no better way to communicate with them than email.

If you don't mind I'd like to keep this ticket open until the corrected Polish translation lands in this github repo.

[monsta]

I think all the translations should be updated by now, please check.

[rluzynski]

Sorry, I can't see any change in the plurals rules in any Polish translation file. I can see the files have been updated but plurals are wrong. I know the problem is in transifex so I suggest to wait for the solution.

I tried to contact the translators and got some response but still I can see the translations are wrong. Please keep this issue open.

[monsta]

Hmm... not even a single package is fixed? 😕

[rluzynski]

Really, not even a single package. Just to make sure we are talking about the same: it's about Polish language (pl.po) and not about a particular translation being wrong but about "Plural-Forms" line which is incorrect everywhere under mate-desktop. There are few changes in the pl.po files but the plural rules are not changed.

I've sent another email on Friday but I still have no response. I know this seems to be not the best place to complain about translations but transifex does not seem any bugzilla-like system.

[piotrdrag]

I was talking with people at Transifex about this. They switched to what’s provided by CLDR in order to standardize the plural rules. Their stance is that this is an upstream problem that needs to be fixed in CLDR.

[diegobz]

The problem pointed about 14 being taken into account in the few rule has been fixed in Transifex.

About the argument that it should have 3 plural forms and not 4, as @piotrdrag pointed out, CLDR[0] is upstream here and Transifex is following it.

If we can articulate the problem in a ticket on their side that would be great. There is instructions on where to file a ticket with them on the link mention at the beginning of the page.

[0] http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html#pl

[rluzynski]

The problem pointed about 14 being taken into account in the few rule has been fixed in Transifex.

Great!

About the argument that it should have 3 plural forms and not 4, as @piotrdrag pointed out, CLDR[0] is upstream here and Transifex is following it.

If we can articulate the problem in a ticket on their side that would be great. There is instructions on where to file a ticket with them on the link mention at the beginning of the page.

The rule in CLDR is unnecessarily complex but correct. Its complexity may lead to errors as this bug proves.

The other rule in CLDR applies to fractions which are out of the scope of any translation backed by gettext or any similar system. I'm afraid that due to this problem CLDR is not a good source to be followed strictly. On the other hand, one cannot call their rules incorrect.

As I said above, the old rule was simple and correct and didn't need to be changed.

I'm not sure what v parameter means in their rules, it is not explained. Is it a mark that the number is not integer? If yes, then Transifex should first reject all rules with v != 0 and then optimize them.