Follow-up Comment #4, bug #18396 (project freeciv):
I think the lack of localisation of Windows help is related to line endings,
and is a bit of a can of worms (so probably merits more ticket(s)).
I installed the standard 2.3.0-RC1 Windows installer (and also one of cproc's
pre-RC1 builds) and reproduced the problem. Opening up the installation
directory, all text files I looked at have DOS/Windows (0x0D 0x0A) line
endings. This means that documentation files (README etc) open correctly in
Notepad (good) but localisation doesn't work (bad).
In contrast, in cazfi's S2_3 builds, the text files have Unix (0x0A) line
endings, and formatting is fine (but localisation doesn't seem to work at all;
maybe it's not compiled in).
I think the failure mechanism is that many help/ruleset files have text with
backslash-0x0D-0x0A. Without looking at the specfile code, I'm guessing that
it's looking for backslash-0x0A as a thing to discard, and ends up removing
the backslash but not the line break characters, causing (a) failure to match
the msgids for localisation, and (b) bad wrapping and excessive line spacing
in English.
Interestingly, I tried the 2.2.7 installer, and didn't have any problem with
the help -- the wrapping works, and localisations also work (I tried
fr_FR.utf-8 and pl_PL.utf-8). Looking at the text files in the installation
directory for that, they have Unix line endings. I didn't try changing them to
DOS line endings and seeing if that broke 2.2.7.
I don't know what accounts for the difference in line endings between the
2.2.x and 2.3.x Windows builds. In the tarballs/zip files, all files have Unix
line endings. So I guess it's either something in the "make install" step or
in cproc's installer-building step. I could imagine it varying based on the
precise build process (Cygwin/MinGW/what-have-you).
The quickest way to fix this for 2.3.0 would probably be to revert whatever
changed in the installation/packaging procedure between 2.2.x and 2.3.x; this
should get localisation / formatting back.
However, in the longer term, it would be good for the text files in the
Windows distribution to actually be openable with the default Windows text
editor (pro tip: WordPad can cope with Unix line endings).
Looking at the code, the decision whether to open the file in "r" (text) or
"rb" (binary) mode seems to be in fz_from_file(). I'm slightly suspicious of
this code; it seems to me that if HAVE_LIBBZ2 is defined, the probing code
leaves "b" in the mode, even if FZ_PLAIN is eventually decided on as a method
(as is correct for the Windows installations -- helpdata.txt is
uncompressed).
However, even if that's true, I'm not sure that fixing it is a complete
solution; if helpdata.txt were compressed (which would be reasonable),
presumably the file contents come out in "binary" mode regardless? So, I
suspect that the specfile-reading code needs to explicitly cope with different
styles of line endings. That's not an entirely trivial or risk-free change.
(I'm a bit nervous about opening files in "r" mode, anyway -- is there a risk
that on some platform, the OS would try to do character encoding conversions?
I think our specfiles are defined to be in UTF-8 regardless of platform, and
that's important for the nation files.)
(I haven't even thought about whether there's a problem with Mac-style line
endings. Are they still even relevant, or did they die with the classic Mac
OS?)
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?18396>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
