[Freeciv-Dev] Re: Client Side Translation
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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
|
|