Description of problem: When a translator upload a po file that contains Plural-Forms that is different from server (e.g. Bug 1197283), it should show following error message and stop the process: "Plural-Forms in <locale>.po conflicts with server" This should depends on Bug 1184708, so admin can specify the correct plural form. Version-Release number of selected component (if applicable): Zanata 3.5.1 (git-server-3.5.1) How reproducible: Always Steps to Reproduce: 1. In web UI, Set the Plural-Form of kn to: nplurals=2; plural=(n != 1); 2. From anaconda project: https://fedora.zanata.org/project/view/anaconda Download the kn.po 3. Change the Plural-From in kn.po to "nplurals=1; plural=0;" 4. Upload kn.po Actual results: PluralsForm was updated to "nplurals=1; plural=0;" Expected results: Show error: "Plural-Forms in kn.po conflicts with server" Additional info:
Zanata is meant to support per-file plural forms (for certain rare cases, including Chinese I seem to remember). So I don't think this should be an error, but we should have a warning when this happens. And if using this feature causes problems, they should probably be treated as bugs. Also, bear in mind that the same plural rules can sometimes be specified in slightly different ways.
(In reply to Sean Flanigan from comment #1) > Zanata is meant to support per-file plural forms (for certain rare cases, > including Chinese I seem to remember). So I don't think this should be an > error, but we should have a warning when this happens. And if using this > feature causes problems, they should probably be treated as bugs. Now that I think about it, those rare cases are probably so rare, especially in technical documents, as not to be worth the cost of supporting them properly in Zanata. So perhaps it *should* be an error. If the problem comes up (eg someone has an old Arabic PO file with nplurals=5), it should not be difficult to write them a command-line script to migrate the PO file. > Also, bear in mind that the same plural rules can sometimes be specified in > slightly different ways. Even so, the nplurals number should match, so we can check that.
Hi Sean and Dean, I agree that if it's very edge case that would rarely happens and if we are not going to implement anything in next 6 months to a year, I would rather save the resource and effort for some other bugs that are more urgent. I can close this bug as DEFERRED so that when we have more resources available, we can take a look at it again if there's real error use cases reported. Please re-open the bug if you feel there is still need for any development effort. Thanks.
Michelle, RFE Bug 1184708 is pretty much useless until we implement this. The current behavior is, the plural form is from the uploaded/pushed po file. and it downloads as-is. In other words, the server-wide plural form that Bug 1184708 implemented will not be used.
Supporting multiple plural forms for the same language is the rare edge case. Getting bugs because of incorrect/mismatched plural forms is something which has already happened. Checking nplurals should not be too difficult. Dean, could you please add a link to the bug which occurred when a PO was uploaded with a bad value for nplurals?
(In reply to Sean Flanigan from comment #5) > Supporting multiple plural forms for the same language is the rare edge > case. Getting bugs because of incorrect/mismatched plural forms is > something which has already happened. > Checking nplurals should not be too difficult. Exactly, so that why I suggest error should be shown when someone trying to push the "unofficial" plural-forms. I also agree that checking nplurals should be sufficient on this stage. > Dean, could you please add a link to the bug which occurred when a PO was > uploaded with a bad value for nplurals? Bug 1197283
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-147