| Summary: | Zanata accepts PO files with too few plural forms | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Zanata | Reporter: | Sean Flanigan <sflaniga> | ||||
| Component: | Component-Logic | Assignee: | Sean Flanigan <sflaniga> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Joyce Chang <jochang> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 1.6-SNAPSHOT | CC: | petersen, zanata-bugs | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 1.6-beta-1 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Zanata version 1.6.0-beta-2-SNAPSHOT (20120523-0019). | Doc Type: | Bug Fix | ||||
| Doc Text: |
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.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-06-22 00:58:17 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 803572 | ||||||
| Attachments: |
|
||||||
Changed server to canonicalise translation state based on the number of translated plurals compared to nplurals for the document/language. https://github.com/zanata/zanata/commit/1c584d00965103770bd1dfe08391ba2339525d51 Please check with the Maven client and with Python.
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.
Zanata version 1.6.0-beta-2-SNAPSHOT (20120523-0019). |
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.