Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2000:
[Freeciv-Dev] Re: Client/Server localization problem
Home

[Freeciv-Dev] Re: Client/Server localization problem

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx (Freeciv developers)
Subject: [Freeciv-Dev] Re: Client/Server localization problem
From: Reinier Post <rp@xxxxxxxxxx>
Date: Fri, 22 Sep 2000 01:07:49 +0200

On Thu, Sep 21, 2000 at 06:16:22PM +0200, Dirk Stoecker wrote:
> Hi,
> 
> Freeciv has a general design problem in case server and client run with
> different languages. As the server also sends formated texts, this cannot
> be solved easily.
> 
> Possible solutions would be:
> 
> 1) The strings are no longer sent, but new packets are introduced and the
> clients create the strings from packet data.
> 
> 2) The server does no longer format the strings itself, but sends the
> string and the arguments and the client formats them.
> 
> 3) Anything I have forgotten????

     The server maintains a client language for each client
     and formats the strings relative to the client they will be sent to.
 
> Both solutions aren't that easy (Well would have been better to design the
> first versions of Freeciv with localization in mind).

3) isn't any better, as far as I can see.

> The first solution seems to be much cleaner to me, so here an example
> transfer structure (I do not know much about current design, so this
> reflects a way I would do it):
> 
>   - int size of block  /* These two are for identification */
>   - int type of block  /* I think freeciv has already a system for it */
> 
>   - int Number of arguments
>     - int argument type
>     - int argument
> 
> Where argument type stores the data type:
> #define TRANSFERTYPE_STRING           0 (string id)
> #define TRANSFERTYPE_VALUE            1 (a number)
> #define TRANSFERTYPE_UNITNAME         2 (data is unit id, result is unit name)
> #define TRANSFERTYPE_CITYNAME         3 (data is city id, result is city name)
> #define TRANSFERTYPE_PLAYERNAME       4 (data is player id, result is city 
> name)
> #define TRANSFERTYPE_TECHNAME         5
> #define TRANSFERTYPE_NATIONNAME       6
> #define TRANSFERTYPE_NATIONSNAME      7
> #define TRANSFERTYPE_IMPROVEMENTNAME  8
> ...
> 
> The strings are then stored in a larger field on client side and addressed
> with the field index.

Although it has clear advantages, I think this is a bad idea.
See the thread starting at

  http://arch.freeciv.org/freeciv-dev-200008/msg00233.html

-- 
Reinier



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