Here is a patch for the bug described in
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470
It follows the latest Martin followup as I understand
it. I'm not sure if multi-lines field handling should
be totally discarded while reading metadata headers (as
implemented), or if it should only be discarded for the
content-type and plural-forms header. If one think this
patch isn't correct, please comment so I can fix it.
Notice that if the second solution was intended, lines
such as
"#-#-#-#-# fr.po #-#-#-#-#\n"
inserted by msgcat/msgmerge will have to be treated
differently (i.e. multi-lines support but skip lines
begining with a #).

Logged In: YES
user_id=21627
The patch is wrong; it breaks the existing test case
WeirdMetadataTest. I think the "just a single line" rule
should be restricted to Plural-Forms; not sure whether it
should apply to content-type also (but why not).
I'll attach another patch that adds a test case.

Minor change request.
+class Bug1448060(GettextBaseTest):
Can you name the test class something more meaningful like PluralFormsTest or something like that. It is helpful when looking at it later. (Btw, this can be done by the committer during checkin too)

Could you follow the guidelines at http://www.python.org/dev/patches/ to create patches? Thanks in advance.
I wonder why you call tearDown from setUp. Doesn’t unittest do that for you when there is a failure in setUp? Also, you could use a with statement instead of try/finally.

This looks similar to https://bugs.gentoo.org/show_bug.cgi?id=373115. Is it the same thing, or should I file a separate bug for it? (Sorry, I don't intend to hijack this bug, but I don't know much about gettext and the patch here looks somewhat similar to the patch proposed there.)