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 Freecivfirstname.lastname@example.org https://mail.gna.org/listinfo/freeciv-dev