Follow-up Comment #26, bug #18396 (project freeciv):
>>> I wonder if line endings simply have to match those used when
>>> freeciv.pot has been created (msgstrs collected)...
>> By accident, I found that that is the case, yes. However,
>> relying on this will be fraught when cross-compiling.
> Ouch. Any pointers? I think I'll take this to gettext mailing
> list (if you don't want to).
I spoke too strongly, I think. (Executive summary: panic over.)
What I actually observed was that the line endings in data/helpdata.txt in
the build tree at "make dist" time had an effect on how the matching worked at
runtime (presumably due to the .gmo files being different).
What actually happened was that I had a version of helpdata.txt with *mixed*
line endings (mostly LF, some CRLF, some LFCR), because I was stress-testing
patch #2843. I wanted to drop this in my install location at runtime, but in
fact I had accidentally left the mixed-line-endings version in the build tree
at "make dist" time. When I then put in a Unix-line-endings version in the
install location at runtime, I was surprised that the few help entries I'd put
in funny line endings were *not* being localised, despite the trick version of
helpdata.txt being nowhere to be seen.
Now I investigate, it appears that it's the weird LFCR line endings that
foxed it. Converting all or even just part of the build-tree helpdata.txt to
CRLF line endings is not sufficient to cause fr.po to get mangled by "make
I think it's perfectly reasonable for gettext not to cope with this.
(For the record, my gettext is 0.17-8ubuntu3.)
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list