🚀 go-pugleaf

Kevin Cline (kcline@sun132.spd.dsccc.com) wrote:

|> I assume you are talking about an interface like

|>   MessageId.H:
|>   ------------
|> 	enum { DOOR_LOCKED, MONSTER_SEEN, ... } MessageId;

|>   Message.H:	
|>   ----------
|> 	#include "MessageId.H"
|> 	void message(MessageId, const char* fmt, ...)

|> with some data file that is compiled to produce MessageId.H, and also
|> a run time database of message formats for various languages.

More or less.

|> For C++, I would compile the data file to produce a class definition
|> for each message, instead of just an enum identifier, e.g.

|>   Messages.dat:
|> 	FoundObjectMsg(string color, string type) {
|> 	  ENGLISH(There is a %s %s here,1,2)
|> 	  SPANISH(Aqui esta un %s %s,2,1)
|> 	}
    [Rest of example cut...]

|> Sorry for my pathetic monolingualism.

Which is exactly the problem.  Most programmers don't know *all* of the
worlds languages, at least not well enough to write messages in them
that would be acceptable to a native speaker.  So the translations are
typically done locally, after the program is written and compiled.
Results: you cannot have the messages in the code.

|> This scheme is typesafe, and no more expensive in time or space
|> than non-typesafe methods.  There is a minimal cost at compile time.

This scheme still doesn't address a major problem: word order varies
from one language to another, so in some languages, you will have to
insert the color first, in others, the type (to take your example.  In
fact, I suspect that this is the case between English and Spanish; if
Spanish is like Italian or French, the color should come after the noun
it modifies, and not before.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung