poedit does not recognise CR/LF in PO files

[Ken Sharp]

Binary package hint: poedit

poedit is not recognising when PO files have CR/LF / line breaks. The result being that there doesn't appear to be any when using poedit and when saving they are removed altogether.

To recreate:

1. Open the attached sample file in poedit and gedit and compare the two.
2. Save poedit.
3. Open the file again in gedit. You will see the line feeds have gone.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: poedit 1.4.2-5
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Mon Jun 14 11:06:52 2010
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: poedit

[Václav Slavík (vslavik)]

This is certainly not true as described -- even the attached sample file shows plenty of newlines. Are you referring to this upstream bug: http://www.poedit.net/trac/ticket/25?

[Ken Sharp (kennybobs)]

The attached sample hasn't been edited yet. I added it so someone could test it if they wanted to.

It certainly does look like http://www.poedit.net/trac/ticket/25
So it removes the wordwrap but doesn't affect line feeds?

I'm sure there used to be a way to attach a Launchpad bug to a URL but I can't seem to find that option now.

[Václav Slavík (vslavik)]

> So it removes the wordwrap but doesn't affect line feeds?

Yes. Specifically, it doesn't preserve insignificant formatting of the source files.

[Gianfranco Costamagna (costamagnagianfranco)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running apport-collect <bug #> and any other logs that are relevant for this particular issue.

[Ken Sharp (kennybobs)]

Still present in Precise