Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: Client Side Translation
Home

[Freeciv-Dev] Re: Client Side Translation

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Michael Stefaniuc <mstefani@xxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Client Side Translation
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 31 Oct 2001 01:21:50 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

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?

> > 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?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "That's fundamental game play!  My main enemy is *ALWAYS* fighting 
  a 4-front war.  I make sure of it!"
    -- Tony Stuckey, freeciv-dev


[Prev in Thread] Current Thread [Next in Thread]