<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40028 >
> [wsimpson - Mon Jan 21 09:51:15 2008]: > > Madeline Book wrote: > > Oh wow, it really was trivial! But certainly not obvious > > for the likes of me :(. Once I ran the client with LANG= > > fr_FR.UTF-8 the libc messages displayed correctly and gtk/ > > pango was very happy. > > > Nor to me. Leaving open until this is documented on our web pages and in > the distributed files. This is a bug in freeciv. Background: when I wrote the charset code, I divided freeciv into 3 charsets. The local charset is the one supported on the command line: this one is not under our control, and all output to the command line must be converted into it. The internal charset is the one used internally within freeciv: this is always utf-8 at the server but can be configured by the GUI at the client side (GUI writing is a lot easier if your charset is the same as your GUI library's). Meanwhile the data charset is the one used in all data files and network transactions and is utf-8. Now, the relevant point here is that while freeciv strings as translated by _() go directly into the internal encoding (see bind_textdomain_codeset in fciconv.c), anything returned by a library is going to go into whatever encoding that library uses. In the case of libc, this is the local encoding, and thus any translatable strings returned by libc need to be converted before they can be used. This can't really be changed; although we could hack the local encoding to switch to UTF-8 or just change the libc domain to return strings in that encoding, this would be poorly portable and would also cause stuff printed to the command line directly by libc to be in the wrong encoding. The functions to do the conversion exist in fciconv.h and are the same ones used for reading data from the command line: local_to_internal_string_malloc and local_to_internal_string_buffer. It would be nice to have a shortened form of these (like L_()), as has been discussed before, but since iconv requires a buffer into which to stick results this buffer must be either provided or allocated. Declaring the buffer statically is tempting but would lead to hard-to-trace bugs when L_() was used twice at once; some sort of garbage collection or buffer-rotating scheme might also come to mind for this. Perhaps #define L_(t,b) local_to_internal_string_buffer((t),b,sizeof(b)) might be the best way to go. Of course the real work lies in finding all the places where L_ should be used...which will require either a full audit or just fixing it as bugs are reported. The latter would be the easiest place to start as we already have a concrete bug report of a few and it's not likely too many libc-translated strings are being used internally within freeciv. So in summary, if any bug reporters can track where the offending strings are coming from, fixing each incident is not too hard. In the meantime this should be listed as a known bug. -jason _______________________________________________ Freeciv-dev mailing list [email protected] https://mail.gna.org/listinfo/freeciv-dev
