Last modified: 2013-03-10 13:28:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T27120, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25120 - Stray newlines at end of some messages break .po -> .mo compilation
Stray newlines at end of some messages break .po -> .mo compilation
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Translate (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-09 18:01 UTC by Brion Vibber
Modified: 2013-03-10 13:28 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2010-09-09 18:01:48 UTC
msgfmt freaks out when it sees a message that ends with a straight newline in original but not in translation, something that I've seen creep into translations a number of times.

Error messages look like this:

  locale/cs/LC_MESSAGES/statusnet.po:5904: `msgid' and `msgstr' entries do not both end with '\n'
  locale/ka/LC_MESSAGES/statusnet.po:5443: `msgid' and `msgstr' entries do not both end with '\n'
  locale/ka/LC_MESSAGES/statusnet.po:5568: `msgid' and `msgstr' entries do not both end with '\n'
  locale/ka/LC_MESSAGES/statusnet.po:5606: `msgid' and `msgstr' entries do not both end with '\n'
  locale/ka/LC_MESSAGES/statusnet.po:5649: `msgid' and `msgstr' entries do not both end with '\n'

Siebrand thinks this may be due to extra whitespace inserted by the JS code, so you end up with " \" instead of "\" for the final line.

They can be manually cleaned up once noticed, but there's a few things that could help prevent them:

* during editing, see if we can avoid the extra space insertion
* at save time, see if we can detect the mismatch and throw a warning for the translator to fix it
* at .po export time, see if we can detect the mismatch and either throw a warning or silently fix it in the output
Comment 1 Niklas Laxström 2011-07-11 11:54:51 UTC
It still puzzles me why this is only a problem for Statusnet. Preferably messages should not end with a whitespace.
Comment 2 Siebrand Mazeland 2011-07-11 17:32:52 UTC
What is mentioned in comment 1 is exactly the issue. In particular, when messages end with a newline ("\n") that was noted in Translate using a single "\" without leading whitespace. However, we use to have TM suggestions that did insert whitespace at the beginning of every line, or if translators copy-pasted the TM suggestion instead of using the JavaScript insert arrow, it might also have leading whitespace. Annoying, but almost impossible to fix, because however unlikely, " \" (a single space) might be valid message content in gettext.

The only fix that I see is save time time gettext validation (source to translation) for exactly this issue, and if the "entries do not
both end with '\n'" just mark it fuzzy. Is that possible, Niklas?
Comment 3 Siebrand Mazeland 2011-09-03 17:41:07 UTC
This should maybe be a JS based check, based on the source message for gettext groups, or done "on save".

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links