When a string contains a carriage return ("^M"), the gettext exporter should show that as \r.
Otherwise there will be problems when re-importing the exported file: the importer sees a CR and treats it as a newline. So it bails out with an error about the fact that there seems to be no closing quote on that line. And when the user checks the file on their own machine, msgfmt says nothing because it does not treat the CR as newline.
Escaping the things will not solve all problems we have with carriage returns, but it'll make it a lot easier to see what's going on.
Related problems are in bug 61112 (similar but for the UI), bug 88831 (importer choking over the incoming CR), and bug 61096 (allowing mixed line endings in a single file).
(I was pretty sure there was a bug about this already, but I can't seem to find it today).
Fixed in RF 7653