Re: [Freeciv-Dev] Internationalization
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
David Perez Serrada asked me to forwad the following to the list:
------- Start of forwarded message -------
Date: Wed, 14 Jul 1999 09:39:34 +0200
From: David =?iso-8859-1?Q?P=E9rez?= Serrada <dperezs@xxxxxxxxxxxxxxx>
To: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1
David Pfitzner escribió:
> First a disclaimer: I don't think we need to solve all of
> these problems all at once. It should be fine to add initial
> limited gettext support, with possibly only a few "easy"
> strings initially marked for translation, and then work on
> improvements from there.
Yes, I have doing some work on it, and now the logs messages
are not translated at all.
> People interested in doing this should probably try to
> coordinate. People who I know have worked on this or
> indicated interest, now or previously, are in the CC.
> (But there may be others.)
Well, I'm working on it now, but I prefer not to send a patch until
something useful (or stable) is done.
> Ok, some problems:
> 1. Client-server issues. It would be good to be able to
> have clients and servers localized to different languages,
> and still have players see all messages in their own language,
> including messages sent by the server. The main issue here
> is whether the translation is done by the client or by the
> server (where the client would tell the server what language
> to send).
Yes, is a good thing, but in the version I'm doing i suppose that
client and server speak the same language, (of course, it's only
a temporary state of things).
> A possible problem with the server doing the translation is
> that I think with gettext it may be inefficient to change
> which language is being used. So if the server sends out
> lots of messages (eg at end-of-turn) and has to keep changing
> its language bindings, it may be too slow.
I dont think it suppose a really problem, but I'll make some test.
> (Actually, this would imply some re-structuring even if the
> server did the translation when sending to clients, since
> currently the server will typically compose a message from
> components before knowing which client(s) the message will
> be sent to.)
Is very difficult that the client make the translation cause the server
make a compose of messages. The server could make a translations
of the components of the messages and then translate it, but it will be
imposible to translate this by the client.
If you want to send that Seville has the Magallean Expedition, the
could make the following:
sprintf(buff,_("The city of %s has %s\n"),city,_(wonder));
and in the po file:
msgid="The city of %s has %s\n"
msgstr="La ciudad de %s tiene %s \n"
msgstr="Viaje de Magallanes"
But It will be imposible to the client translate the following phrase:
"The city of Seville has Magallean Expedition"
unless, of course, we send the components, but this will change a lot
> A possible solution is for the server to not send a fully
> built string, but to send a format string (probably not printf,
> but maybe similar) and other strings to plug into the format,
> where the client then translates the format string, and selected
> of the other strings, I guess based on the format specifier,
> before plugging in the extra strings.
But what happends with ruleset, server is which change the ruleset
and have the files, so if the server use a new ruleset it have to send
the clients and that the client translate it. I think that the server
translate the messages and send to the client (of course the client have
make some translations the menus, dialog boxes,etc..)
> 2. Data files. Currently unit names etc are stored in ruleset
> files, which are read in by the server and then the information
> is sent to clients. For the client to have appropriate translations,
> I think the translations need to be inside the ruleset files.
> Otherwise the client may use completely inappropriate names if
> the server used a customized or changed ruleset file.
I the version I'm doing i mark the string that have to be translated
in the ruleset file as same i do in the C files. The registry routines
could detect this marks. The translation will a only send to the client,
the server use the english version. The translation will be in the po
of course this is a problem, whenever a new ruleset is done, the po
file will have to be redone.
Other way of doing that is to have diferent ruleset for each language:
and so on.
> For generic helptext, each entry in the helptext could have multiple
> sections for different languages; or there could be multiple separate
> helpdata_*.txt files, one per language; or multiple files where the
> default is read in first and then a language-specific version is
> read-in after and overrides some entries. An issue here would be
> whether one of these methods makes it easier to keep translations
> up-to-date, but I'm not sure which...
The same as in the ruleset, or mark the strings in text file and
it on po files or make it a separate file. I don't know wich will be
> 4. Sentence generation, grammatical contructions. In some places
> freeciv automatically generates some sentence elements, such as
> using "a" or "an" before a noun, or adding a location qualifier
> to a message. I guess this will cause some problems.
Really a good problem
5. data/Freeciv (Xaw client only). This file is usable as an
X resources file, and is also compiled into the client. It
contains some strings which should be translated. It would be
possible to providea a translated resouces file, but a danger
is that an out-of-date resources file can easily crash the
client, or create bad visual effects, or effectively give
broken dialogs. And I'm not sure whether all available
translations of the resources should be compiled in...
I'm doing the translation in the GTK client, is more easy, and
I have not idea how to make it in Xaw client :(
------- End of forwarded message -------
Re: [Freeciv-Dev] Internationalization, Martin Christensen, 1999/07/14
Re: [Freeciv-Dev] Internationalization, Artur Biesiadowski, 1999/07/14