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.

Logged In: YES 
user_id=21627

Couldn't get to it before 2.5; forwarding to 2.4.4/2.5.1

Attached patch is my take on the fix to this, it's a two line change to gettext.py for 2.7.  If the change is accepted I'll provide another patch for py3k.  Nosy list updated while I'm at it.

Sorry, forgot to say that the patched code passed all tests in the patched unit test file.

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)

Point taken I'll settle for PluralFormsTest unless there's a better idea.  Assuming patch acceptance could a committer do this please?

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.)

It's difficult to tell whether it's the same thing. Is the po file in question available readily for inspection?

Looks like this was the problem: http://git.fedorahosted.org/git/?p=virt-manager.git;a=commitdiff;h=cb56316cf3702f03b05e30f406ff3028e45f7bfb.

E.g., the empty Plural-Forms header is throwing off the python gettext parser.

Ok. This is a different issue, then.

Okay, I've filed issue12425.

I think that #17898 is in fact a duplicate of this bug, due to old values of k and v confusing things.  Mark's patch looks correct to me, but the patch in #17898 also adds a test.  If that patch gets reviewed, I'll apply it to 3.4/3.5, and possibly to 2.7.

#17898 has been closed with basically the same fix as Mark's patch, so I'll close this issue.