Re: [Adonthell-devel] i18n progress

[Kai Sterker]

On 16 Mar 2002 13:10:25 +0100 Alexandre Courbot wrote:
 
> Where would it be added? Don't forget gettext doesn't only apply to
> dialogs, but also to menus, and so on... It should therefore be
> globally accessible.

It's globally available for the whole engine, of course. For things like
the schedule scripts, the translation would occur on Python side, for
the dialogue engine it is done on C++ side.

It might be neccessary to have our own gettext layer. After all, there
is only one function we must make available to Python scripts: gettext.
Everything else is handled by the engine. That means it would work with
versions of Python that came without gettext support. That's probably
better than forcing everyone to upgrade to Python 2.1 or greater if they
could be using older versions as well. 


> Don't you use the same one as Waste's Edge? Or have you improved stuff
> again? :) I thought you were only rewriting dlgedit.

Well, I took the opportunity to improve things a bit. If everything
works as I expect, there is one python dialogue class from which all
actual dialogue scripts inherit. This base class contains some code,
whereas the dialogue classes contain mainly data. That has a couple of
advantages: 

[*] the dialogue compiler is much simpler, as there are no more special
cases. That also helps preventing errors in generating the dialogues. 

[*] most code contained in the dialogue is executed via the eval()
function. That means, errors in that code are caught by an exception and
no longer interrupt the dialogue script.

[*] some ugly dependencies between dialogue scripts and engines have
been resolved

[*] and finally, the dialogue files are only half as big as they were
before (not that size would be an issue, but still ...)

All in all, the interface of the C++ dialogue engine remains unchanged.
Only the interface to the dialogue scripts (and the scripts themself) is
different. 


> Does it mean that translations are done within dlgedit? That would be
> great for user-friendlyness, but in this case each dialog would be
> contained in it's own catalog, right? 

No. That wouldn't really work, I think. After you finished a
translation, you can view the result in dlgedit. That's more convenient
than testing the translation in the game, as that makes certain parts of
a dialogue difficult to reach. But if you spot an error, you'll have to
correct it by hand in the catalog source, then regenerate the binary
catalog file. Maybe, at a later stage this could be automated, but right
now I don't even want to think about that ;).

Anyway, for this feature, it does not matter whether all translations
are in a single or in different catalogs. You load a catalog, and if it
contains the text of the dialogue you have currently loaded, the
translation is applied, otherwise it isn't.


> Wasn't our goal to only have one
> catalog per game, which contains all the strings, so it is loaded once
> at game start? 

Exactly. That's what we will do. Actually, I would suggest that we offer
an option for the player to chose a certain language at runtime. That's
more convenient than having to alter or set environment variables. But
even then, we would only use one catalog, but discard it and load
another one if the player switches the language.

Kai