Cause
A message in a PO file has fewer msgid_plural entries than the specified number of plurals in the header (or the nplurals header is missing), but the msgid_plurals which are present have been filled in.
Consequence
The incomplete message is treated as Approved, and shown in green in Zanata's UI.
Fix
Server checks number of translated plurals against nplurals or the locale default nplurals, generates a warning, and adjusts the message status accordingly.
Result
A warning is returned to the client, and the incomplete message is shown as New in the UI.
Created attachment 578486[details]
PO file with missing plural form
Description of problem:
Malformed PO files may have fewer msgstr[] entries than nplurals (or the header may not define nplurals at all). Such invalid files are rejected by msgfmt -c, but are currently accepted by Zanata (client and server).
Note that these invalid files would generally only be created by hand in a text editor; I believe most gettext-aware tools/editors would set nplurals appropriately and then check the file against it. If a translation is created from scratch in Zanata, nplurals will be set and checked. This problem only arises if an invalid PO file is imported.
Version-Release number of selected component (if applicable):
Zanata version 1.6-SNAPSHOT (20120418-0012).
How reproducible:
Steps to Reproduce:
1. push the file missingplural.po to a suitable Zanata project using mvn zanata:push
2. open the document missingplural in the translation editor
3. observe the state (colour bars) for the string s2
Actual results:
Translation of string s2 is marked with content state Approved.
Expected results:
Translation of string s2 should be marked with content state New. Or we could reject the file from being imported.
Additional info:
This will most likely happen with the Python client as well. However, we should probably have the *server* calculate the correct content state, rather than expecting each client to calculate it separately, and hoping they are consistent with the rules being checked on the server.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause
A message in a PO file has fewer msgid_plural entries than the specified number of plurals in the header (or the nplurals header is missing), but the msgid_plurals which are present have been filled in.
Consequence
The incomplete message is treated as Approved, and shown in green in Zanata's UI.
Fix
Server checks number of translated plurals against nplurals or the locale default nplurals, generates a warning, and adjusts the message status accordingly.
Result
A warning is returned to the client, and the incomplete message is shown as New in the UI.
Created attachment 578486 [details] PO file with missing plural form Description of problem: Malformed PO files may have fewer msgstr[] entries than nplurals (or the header may not define nplurals at all). Such invalid files are rejected by msgfmt -c, but are currently accepted by Zanata (client and server). Note that these invalid files would generally only be created by hand in a text editor; I believe most gettext-aware tools/editors would set nplurals appropriately and then check the file against it. If a translation is created from scratch in Zanata, nplurals will be set and checked. This problem only arises if an invalid PO file is imported. Version-Release number of selected component (if applicable): Zanata version 1.6-SNAPSHOT (20120418-0012). How reproducible: Steps to Reproduce: 1. push the file missingplural.po to a suitable Zanata project using mvn zanata:push 2. open the document missingplural in the translation editor 3. observe the state (colour bars) for the string s2 Actual results: Translation of string s2 is marked with content state Approved. Expected results: Translation of string s2 should be marked with content state New. Or we could reject the file from being imported. Additional info: This will most likely happen with the Python client as well. However, we should probably have the *server* calculate the correct content state, rather than expecting each client to calculate it separately, and hoping they are consistent with the rules being checked on the server.