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

Reply via email to