On 04/07/2016 04:26 PM, Pavel Sanda wrote: > Richard Heck wrote: >> Using autotools, this is done via the msguniq program. I cannot tell how >> it is done with cmake, but I suspect that this is where the error >> occurs, and that this is why you get "\r" in the middle of some lines, >> namely, we get: > Then we are back at the old problem we were never able to figure out, > namely why gettext on win and linux behave differently when it comes > to line breaks. There were several threads about this, the most recent > one AFAIR: > > http://thread.gmane.org/gmane.editors.lyx.devel/125776/focus=125759 > > We first thought is poedit fault, but after reporting one bug to its > developers and having it fixed, Uwe still got different .po files and we > concluded there's another gettext/msguniq issue and never followed on this > one.
I think the problem may not be that gettext works differently but, perhaps, that it works the same. I am guessing that what happens is this. First, lyx_pot.py writes the po files with native line endings. I.e., when we say: print "this\n", what actually gets written on Windows is: this\r\n. Now we have a bunch of \r\n. Then these files are passed to whatever other program to remove the duplicates. I gather from what you say that this is msguniq under autotools and gettext under cmake. But, if I'm right, then, if you're on Linux, you never get \r\n in the first place, and it's not that gettext is acting differently but rather that when it does the line unification thing, it only removes \n not \r\n. So we end up with a bunch of stray \r. Maybe a simple solution would be to add something into CMakeLists.txt that would strip all the "\r" before sending the files through gettext. Richard
