Am Donnerstag, 7. April 2016 um 17:02:42, schrieb Richard Heck <rgh...@lyx.org> > 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.
Maybe, see my other mail. But I prefer the solution with help of git.
> Richard
Kornel
signature.asc
Description: This is a digitally signed message part.
