[Freeciv-Dev] Re: Client Side Translation

[Michael Stefaniuc <mstefani@xxxxxxxxx>]

On Wed, Oct 31, 2001 at 01:21:50AM +0100, Raimar Falke wrote:
> On Tue, Oct 30, 2001 at 10:33:50PM +0100, Michael Stefaniuc wrote:
> > 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.
> 
> So what is allowed/supported? s,d,x?
d,i,o,u,x,X,c,s,p,P and also C (only a synonym for lc but shouldn't be
used).

> > > 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). 
> 
> Why is this/can turn into a problem?
Using the struct as examble: the members of a struct can be differently
alligned on different OS'es/archs; an int/float can be a member of a
struct and therefor we get problems with the endianess.
And  put_uchar_vec isn't similar to memcpy: memcpy takes as src
a void pointer whereas put_uchar_vec uses unsigned char.

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