Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
Re: [Freeciv-Dev] Internationalization

Re: [Freeciv-Dev] Internationalization

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Internationalization
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Thu, 15 Jul 1999 14:05:38 +1000 (EST)

Matthew Ryall wrote:

> David Pfitzner wrote:
> > Martin Christensen <factotum@xxxxxxxxxxxxxxxxx> wrote:
> >
> > >   Now, about the server telling the client what text to display and
> > > how, wouldn't it be easier to just enumerate all standard messages?
> >
> > I think this is generally a bad idea, because it means you can't
> > easily add or change messages without introducing incompatability.
> But wouldn't it be possible to have a set of 255 (or whatever, tho one
> byte is a nice size) default codes that each stand for one of the
> messages from client to server during the game.

> with a client responding with a standard
> message such as "Server event not understood, please upgrade:
>";, or something such if there was no response
> stored for that particular event.

We already have the problem that from time to time freeciv 
breaks compatability (in a controlled manner) with previous 
versions.  This is defended on the grounds that sometimes 
it is considered necessary in order to progress.

With the above, you are effectively making people upgrade
(or lose possibly important messages) where here it is _not_
necessary: the problem can be easily avoided by sending the 
full message.  Ok, it adds a bit of communication, but I 
think it is worth it.

Furthermore, other than slightly reduced network traffic, I 
don't see any real advantage to this scheme.  It was suggested 
to help translation, but I don't really see it helping.  What
advantage does it have compared to sending a format string and 
using the gettext approach of using the *format string* as the 
index to translations?   Either way you have to send extra 
information to form the completed message.  And the format 
string approach has the advantage of providing a sensible 
fallback if there is no translation available, and being able 
to use the gettext tools to manage the translations.

(The gettext manual, eg,
makes interesting reading related to these issues.)

-- David

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