Multiple language support for csbuild.

[zoom]

Multilanguage add-on (English French German Spanish ... ) for csbuild?

You know, like one of the versions of Dungeon Master(&Chaos Strikes Back as well), where you chose before the actual game which "language version" you wanted to play.
Do you think this is hazardous, having to select this or that language(".. hardly play in a different version, where is the point?"), or do you think it is a "nice feature"(, best to have it in-game active, so that you can have every tick or two(I mean anytime) the language changed, like having experience shown, et cetera (in the smallest resolution scr.)).

Is it doable, and are the people being able to manage willing?
I think the most part would be on the shoulders of Paul Stevens, and later on on the dungeon creators out there.
Is it not somuch of work but unlikely to have any priority in the near future? For whatever reasons.
What about all the custom dungeons? Different items and scrolls would have to be typed three times or more!! ratio of -work-yield
I just thought: there must be some way to implement this stuff and maybe there are still fragments of code in the code not effortlessly, but possible to dig out.
Ok. It is late and i just wanted to tell you i think it would be a great thing, and i´m looking forward to your comments on that.

[TheGleep]

Having just completed a language port, this can be a tough job, but I like the idea.

It would make it necessary to have something for the dungeons to support multiple languages, too, though.

[Trantor]

I don't know how hard this would be to code, but I suspect it wouldn't be very easy. Even if it is possible to do this in a reasonable amount of time, I am afraid that designing custom dungeons will cost too much time. With all scrolls, inscriptions and texts to translate, this will cost a lot of time, especially since I don't think anybody could do this on his/her own. Of course, I could port my dungeon to German, but to French? I would have to ask someone from France to do that for me, and I doubt anybody would be willing to do the task. Translations can also be especially troublesome if you really use a language creatively. If you put in riddles that use rhymes or puns, translating these could be nigh impossible.

All in all, I think it is a good idea, but I fear the effort would be too much. DM is a game that does not contain too much text anyway, and most people here on the forum are good enough in English to get along, I'd say.

[TheGleep]

It wouldn't have to be rebuilding the whole dungeon - just the text it uses. And the text by the engine, of course.

What I've done so far (in my *one* translation project!) was storing the original texts, and using a translation table to convert from original before displaying the text. When rendering the translation table, use a hashtable storing the original text as the key and target text as the value, and it's just a matter of doing lookup in the hashtable.

So, we have the source code modified with "Translate(text)" - which returns the original value if no translation found - and the translation file that's a list of source value=target value pairings. Read the translation file into memory according to language selected (yah - how do we pick language?) as a hashtable.

EB

[Guest]

This is a fine discussion. And your 'hash table' method
of switching text language is pretty much what I did
in the video translations for various platforms and
overlays, etc. ( Apply the modifications at the display
device rather than incorporate the modifications
into the core of the program.)

But, before you spend too much of your valuable time
inventing, developing, and describing techniques that
could be used to provide multiple-language support for
CSBuild and CSBwin, let me make it perfectly clear that
you can expect no cooperation on my part other than
to answer questions, if you should decide to take on the
project yourself, and to provide up-to-date source code
for you to work with.

Paul Stevens

[TheGleep]

Paul! Any way you would be willing to answer questions about how the source code works? I'm starting to work on a Palm clone, and I'd rather make it a "port" than a "clone" (CSB engine only, not csBuild)...

As to being in charge of any translation code....

That works for me.

Of course I've got a LOT more to do before I can understand what I'll be working with.

So no promises on my side, either...

[Paul Stevens]

would be willing to answer questions about how the source code works?

Yes. But 'able' and 'willing' are not the same. I don't offer
free research but will tell you what I know.

[TheGleep]

:That works for me. It's summarized by "how are files arranged to distance OS from Engine?

It *was* you that did the Mac build of DM/CSB, right? I'm thinking the Palm arrangement should mirror the Mac arrangement pretty closely.

I'll even document what I find for future references....

Thanks!

[Paul Stevens]

It *was* you that did the Mac build of DM/CSB, right?

Nope. I did the Windows and PocketPC versions.

how are files arranged to distance OS from Engine

If I understand the question, they are not. No text passes
through the OS except in the menus.

[TheGleep]

Oh - wasn't you? Do you know how to get ahold of who did it?

A bit more on the file arrangement thing...

I figure there is "engine" stuff, which would contain event processing ("event" = "DSA" in my current understanding), and reading/writing from the ?game module? - control file.

Then there's UI/OS-specific stuff like drawing pictures, connection to the system timer, connection to user input.

I'm hoping that within the file arrangement, this separation of purpose is already in place. If not, I'll want to work on that so the next guy to come along won't have to...

[Paul Stevens]

Then there's UI/OS-specific stuff like drawing pictures, connection to the system timer, connection to user input.

Yes, this has been separated pretty well. The same code
compiles and runs on Windows, PocketPC, macintoish,
and Linux. But I thought you were interested in the text.
The text passes through the OS as pixels in the graphics,
not as characters.


The MacOS port was done by Thomas Zahradnicky. See:

http://dmweb.free.fr/CSBForWindowsLinux.htm
for this and Linux port.

[TheGleep]

That's the page that got me interested in doing the port.

Could you give me a brief run-down of which files are "engine" and which are "UI"?

Thanks!

[Paul Stevens]

CSBUI and WinScreen are UI. CSBwin is an extension
of Windows (the message router and window creator).
These three modules feed messages to the game engine,
translate graphics and sound to Windows calls, and
handle error popups.

The rest is game engine.

[TheGleep]

Excellent! So just the two files - CSBUI.cpp and WinScreen.cpp for UI stuff. Does that include input handling?

And where is file-reading managed? Is that in one of those locations?

Thank you VERY much - this will help a LOT. I'll probably ask a few questions about how things interact internally, but I'll make sure to keep it to stuff I think you'll know off the top of your head.

And to not be annoying.

[Paul Stevens]

CSBUI.cpp and WinScreen.cpp for UI stuff. Does that include input handling

You know how windows works? All the Windows messages
pass through a single case statement and are translated
to a message handled by CSBUI. Key-down, mouse-click,
timer, Menu Selection, etc.

And where is file-reading managed

I guess I don't know what 'managed' means. Perhaps
it is not 'managed'. I had to add a layer to translate
between the 16-bit inter file numbers used by the
Atari OS and Windows FILE * structures. Otherwise, file
I/O occurs most anywhere in the program and looks like
Atari File I/O (Pretty much like DOS). Look for 'READ',
'WRITE', 'LSEEK', etc.

[TheGleep]

...All the Windows messages pass through a single case statement ...

Right - but those messages come from *somewhere* - is that somewhere provided by CSBUI.CPP? It looks like there's CSBWin.cpp that probably provides that aspect.

...Otherwise, file I/O occurs most anywhere in the program ...

I was afraid of that. I was hoping that any time a file was read/written was placed in a single location...I'll have to do that myself - I'll send what I get done to you, if you'd like. I'll probably do that first so that I know what I've done doesn't interfere with existing systems.

Thanks for the warning on the file number issues. I'll watch for that code while I'm consolidating.

Thanks again for your sharing!

[Paul Stevens]

but those messages come from *somewhere*

Ultimately from the user pressing the mouse button to
the Windows Message Dispatcher to the Message Pump
to CSBwin. There it is translated pretty much verbatim
(without any processing) and sent to CSBUI.

[TheGleep]

Thanks for the details. Between that and reviewing the code, I *think* I'm ready to start planning how stuff fits together...

I'm sure I'll have more to ask in the future - but I'll try not to be a pain!

[kentaro-k.21]

GNU gettext may be useful in programming approach.

some links about gettext.

gettext - GNU Project - Free Software Foundation (FSF)
http://www.gnu.org/software/gettext/

UNIX man pages : gettext (3)
http://unixhelp.ed.ac.uk/CGI/man-cgi?gettext+3



i knew this technology by pcsx2. pcsx2 is a play station 2 emulator.
pcsx2 supports English and other 10 languages, with gettext technology. (also Japanese)

gettext behaves like "patch", but "translation". it uses PREDEFINED multi language dictionary to convert from a text in native language to a text in other language.

for example, "&Language"'ll be represented "言語" in Japanese.
"&Language"'ll be represented "&Langues" in French.
"&Language"'ll be represented "&Sprache" in German.
and so on...

this can be done by collecting a large amount of pre-translated sentences/words in various languages. (because this is not translate software!)



in C programming side:

prior menu sample "&Language" is brought by following code.

Code: Select all

    ADDSUBMENU(0,_("&Language"));

the "_" is a macro to call "dgettext" C function.

Code: Select all

#define _(String) dgettext (PACKAGE, String)

PACKAGE is a predefined macro. it is a literal text "pcsx2".

Code: Select all

PACKAGE=\"pcsx2\"

if you write code in pcsx2, like following,

Code: Select all

printf(_("Hello"));

transformed into following code due to pre-process result,

Code: Select all

printf(dgettext("pcsx","Hello"));

is it applicable in CSBwin?
i looked at CSBsrc98.

here is a code bit.

Code: Select all

UI_MessageBox("Cannot open ASCIIDUMP.TXT",NULL,MESSAGE_OK);

if you change this code to following style, you can easily get the benefit of gettext technology (but you have to include gettext technology in your program).

Code: Select all

UI_MessageBox(_("Cannot open ASCIIDUMP.TXT"),NULL,MESSAGE_OK);

is it very wonderful way to get the benefit of translation support technology?


be attention:
gettext is from unix system. windows has no native gettext support. you may have to find out the gettext implementation of windows version.

[Paul Stevens]

Before anyone spends too much time on this sort of thing
I had better make it very clear that I will NOT be including
such things in my versions of CSBuild/CSBwin. If anyone
enjoys making a version for their own use then my offers
to help still stand. But the result will not go into my source
code.