[Freeciv-Dev] Re: Client Side Translation

[Michael Stefaniuc <mstefani@xxxxxxxxx>]

Hello!

On Tue, Oct 30, 2001 at 11:10:05AM +0100, Raimar Falke wrote:
> On Mon, Oct 29, 2001 at 05:42:15PM +0100, Michael Stefaniuc wrote:
> > The attached patch starts to implement the first item for the 2.1.0
> > version from http://www.freeciv.org/roadmap.html : "Server should
> > respond to each client with requested language". 
[snip]

> Nice. The only problem I have is that is contains a formatstring
> parser. But I see no way to avoid this. 
Me neither, that's why I tried to keep the format string parser as
simple as possible and why I use my_snprintf to do the conversion of the
arguments.

> Can you write down which
> restrictions now all format strings in freeciv should
The differences described below are in comparison to the printf(3)
man page (Linux Manpage, 16 October 2000). The statement "isn't used in
Freeciv" means that the item to which this refers dosn't appear in
freeciv.pot as of today.
conversion specifier:
---------------------
    n      Makes no sense (no use for it) in the printf_embedded
           implementation. Isn't used in Freeciv.

    e,E,f,F,g,G,a,A     (not used/implemented yet) Floating points aren't
           used in messages from the server to the client. To implement
           them using the POSIX radix char '.' just remove the asserts.
           To implement them correctly would need to transform the
           floats to a string on the server (no portable binary
           represantation/no network byte order for floats), to convert
           them back to a double with atof on the client and transform
           them back to a string in the correct locale.
           Not worth the effort to implement this until we realy need it.

    P      (not in printf(3)) Pointer to a ptrintf_embedded structure.
           Supports all flags, field with, precision like the 's'
           conversion specifier.

    N      (not in printf(3), not used/implemented yet) Like 's' but
           the string isn't translated. I can imagine a situation when
           we could need it: if the name of a player/city matches a
           msgid the name would get translated. I don't know how
           probable this is and if it's worth the effort to
           implement/use it.

length modifier:
----------------
    l      (ell) not allowed for the 's' conversion specifier. If we
           start to use wchar_t (unicode) we would need to do a wchar_t
           to utf8 conversion.

precision and field width:
--------------------------
    *      (not used/supported) Not used in messages between server and
           client (only used on the server console). Would complicate
           the code a lot, should be implemented only when the
           functionality is realy realy needed.

flag characters:
----------------
    '      (not used/supported) Isn't used in Freeciv.

    I      (not used/supported) Isn't used in Freeciv.

the "%m$" format:
-----------------
    Isn't supported in the untranslated format string (and not used in
    Freeciv) but is supported in the translated format string (and
    heavily used in Freeciv). '*' can't be used for 'm' (see comments
    to '*' in the precision and field width section).

> follow. put_uchar_vec should be put_mem (similar to strcpy vs memcpy).
Hmm ... I don't know if it's a good idea because put_uchar_vec
serializes only an array of unsigned chars and not random memory (don't
want to tempt anybody to use it to serialize something else than an
array of chars like e.g. a struct). 

bye
        michael
-- 
Michael Stefaniuc               Tel.: +49-711-96437-199
System Administration           Fax.: +49-711-96437-111
Red Hat GmbH                    Email: mstefani@xxxxxxxxx
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart