[Tool] Easy Gothic Mod Translator

[Sargon]

Version 1.1

• Direct translation of MOD/VDF-Files
• Google-translations and regular translations
• Works for any compatible language

README

Easy Gothic Mod Translator V1.1
----------------------------------------

Direct translator for Gothic MOD/VDF-Files

- For google-translations and regular translations, works for any language
- Openssl is necessary for google-connection (DLLs are enclosed)


Click-through:

- Choose source language and target language, english/german/russian/polish/czech or add a new language via google id and codepage (russian 1251, english/german 1252, polish/czech 1250)

- Import database, utf8 only, simple text-file with 2 columns (source - target) and TAB as separator, or extended file with header as described below, or proceed without database [skip]

- Load mod/vdf-file, which is checked against the database, the scripts will be decompiled and condensed to a table of text+context
For russian source language you have still the more reliable russian dectection, otherwise you have 2 options for detection (saver/riskier), see below

- If there are new lines (not covered by database), they are shown and can be google-translated (in case google blocks your IP temporarily, changing IP should help)
Alternatively with mark and ctrl+c you can get them on the clipboard for any usage

- Then the database can be saved, you can choose between DB[database], MT[mod-table] or both, csv-file as described below

- Then the modfile is translated, there is an option to translate savegames too, you should use the same database as for the mod-version, where the savegame is coming from, so that the quest names are identical.

- Finally the modfile is saved (you can either save all data or just the translated parts as a patch, in the latter case you still need the original file)
Before saving you can edit the timestamp, patches need a newer one than the original (older program versions added +6 years automatically, which is standard for Returning2-AB-updates).


Database:

- The extended database is utf8 only, has 8 columns with TAB as separator (TABs are not allowed as part of text lines, spaces should be sufficient), with the following header:
NR (sequential number), FILENR (file number), ID (symbol id), SYMBOL (symbol name), USE (type of usage), TRACE (backtrace of usage), RU (or EN,DE,PL,CZ,..source language), EN (or DE,RU,PL,CZ,..target language)
The columns must match the header, but otherwise the order of the columns is not fixed, so you can use a RU->EN database for EN->RU as well without changing anything.

- Difference between DB and MT: the ModTable represents the condensed mod-scripts, text lines occur in the same order and quantity as in the scripts (many doubles are possible)
The database is ordered alphabetically (by source language), reduces doubles and can include lines, which are not part of the current mod-file (you can use one DB for several mods)

- Editing the database: you should only edit the target-language-column (unless you know what you are doing), but you should be able to sort the table by USE or TRACE to find all npc/item names etc.
I did not want to include an own table-editor, but you could use LibreOffice Calc - you need to load/save csv with filter: utf8, separated by tab, and without string delimiter (neither " nor ')
Don't use an editor, where after loading and (unchanged) saving the files are not identical!

- In case you change quest titles midgame, the diary will probably not work for running quests with changed names, so starting a new game is advisable


Detection:

- Because of the way how system-strings and translateable strings are mixed up in gothic scripts, there is no flawless way for automatic distinctions between the two,
especially with the vast possibilities of Ikarus/LeGo/AST/Union.

- For russian source language the detection via russian characters is usually quite reliable, for other source languages you have context-detections (usage&backtrace) + assumptions based on script standards
As result of the context-detection you get 3 groups of strings:
1) should/can be translated
2) should/must not be translated
3) context does not exist, or was not detected (some may belong to 1, others to 2, and some are unused/irrelevant)

- The option "safer" will use group 1 only (something may be missing), while option "riskier" will use 1 and 3 (something may cause problems).
Depending on the mod there may be quite a difference between the 2 options or none at all.
Even the safer option may be flawed, so checking the resulting database for text, that should not be translated, is always advisable (for regular translations you go through the whole db anyway).
If you find something, that should not to be translated, you can either delete it from the db (but then it will pop up again as "new line" next time), or better leave it in and just make sure source and target strings are identical


Sargon

 

[Sargon]

I am dealing with an issue regarding easy gothic mod translator. When I import my translation, Viper's 'C_Info_Description' text string applies to Bodo. I will attach a picture to see for yourself what I am on about. Though, I have a question regarding this tool's way of working. The thing is that Bodo's C_Info_Description is totally different compared to Viper's (you can see it in the image). Could you make something to fix this bug of wrongly assigning to prevent any further occurrence of it? I have also decompiled the instance by using union marvin Helper. I will attach that also. Same story is with Harlok's c_info description.

Maybe I could take a look at it if I find the time, but I would need a link to the mod and your whole translation file to test it.

 

[dolorosa]

Maybe I could take a look at it if I find the time, but I would need a link to the mod and your whole translation file to test it.

I have attached the script that I have translated, again, today(the one with the wrong alignment), the original russian script, the torrent of the mod and the translation file.
Thank you!

 

[Sargon]

A fixed translation file should solve your problem for now..

 

[dolorosa]

A fixed translation file should solve your problem for now..

I see that you changed the text string, thanks. But do you know what could be the cause of the wrong alignment?

 

[Sargon]

I see that you changed the text string, thanks. But do you know what could be the cause of the wrong alignment?

Well, it's already a long time ago that I worked on this program.
Seems the symbols (DIA_BODO_HALLO) were not checked, because usually it's enough, when the pair of usage (C_INFO.DESCRIPTION) and source text ("Как дела?") is identical.
But in this special case for Viper there is an unusual translation from "Как дела?" to "Care-i treaba, Viper? Inca mai visezi la minereu?" instead of just "Cum merge treaba?",
and as it probably happended to be the first in the list, it was used for all other (C_INFO.DESCRIPTION/"Как дела?") pairs..

 

[dolorosa]

Well, it's already a long time ago that I worked on this program.
Seems the symbols (DIA_BODO_HALLO) were not checked, because usually it's enough, when the pair of usage (C_INFO.DESCRIPTION) and source text ("Как дела?") is identical.
But in this special case for Viper there is an unusual translation from "Как дела?" to "Care-i treaba, Viper? Inca mai visezi la minereu?" instead of just "Cum merge treaba?",
and as it probably happended to be the first in the list, it was used for all other (C_INFO.DESCRIPTION/"Как дела?") pairs..

In other words the program picks only one unique string, but not all its duplicates, am I right? So I should use a standard "translation" in cases like this? For example "Как дела?" should have the same translation in all its occurrences?

 

[Sargon]

Feel free to test this program version..

Edit: V1.0b removed

 

[dolorosa]

Feel free to test this program version..

What is it you changed at it?

 

[Sargon]

What is it you changed at it?

Well, you can use your original translation file and everything should be where it's supposed to be.
Theoretically you could translate "Как дела?" in how many different ways you want, wherever you want.
But no warranty

 

[dolorosa]

Well, you can use your original translation file and everything should be where it's supposed to be.
Theoretically you could translate "Как дела?" in how many different ways you want, wherever you want.
But no warranty

Cheers! I'll be back if i encounter any issue.

 

[dolorosa]

Well, you can use your original translation file and everything should be where it's supposed to be.
Theoretically you could translate "Как дела?" in how many different ways you want, wherever you want.
But no warranty

Can I ask you one more favor if you don't mind? When exporting the mod-table on a new update in the target language column, the new text strings are shown weirdly. Could all these new text strings in the target language column be empty ( like in the DB file type)? I will put two pictures so you know what I'm on about. So if there is a possibility for you to make the program export the MT file the same way as it does with the DB file when it comes to new text strings in the target language column, that would be really useful. I am using EmEditor and I can just filter-in column the empty lines. That way is way more practical.
Thanks again, you're a wonder !

 

[Sargon]

Can I ask you one more favor if you don't mind? When exporting the mod-table on a new update in the target language column, the new text strings are shown weirdly. Could all these new text strings in the target language column be empty ( like in the DB file type)? I will put two pictures so you know what I'm on about. So if there is a possibility for you to make the program export the MT file the same way as it does with the DB file when it comes to new text strings in the target language column, that would be really useful. I am using EmEditor and I can just filter-in column the empty lines. That way is way more practical.

The weirdly text is the same russian text, just not kyrillc, but with the codepage of the target language, and represents the not yet translated text.
Your request is not so simple as it seems, because MT uses only the full text lines of the mod, while DB uses parts for efficiency.
For example if a line has 3 sentences abc, they will be stored separately in the database, so if you have to translate a new line, which is only partly different, like abd, then a and b will be found in the database and translated while only d will stay untranslated until you do it (that's the case for other separators as well, like lists a|b|c|d).
If I do the change you request, abd will become ab, which is neither an empty line, nor will it be obvious, that something is missing at all.

What you could try for new lines is saving them as DB, filter the empty lines, translate them and append them to your MT.

Thanks again, you're a wonder !

Well, I'm also known as "TheWonderer"

 

[dolorosa]

The weirdly text is the same russian text, just not kyrillc, but with the codepage of the target language, and represents the not yet translated text.
Your request is not so simple as it seems, because MT uses only the full text lines of the mod, while DB uses parts for efficiency.
For example if a line has 3 sentences abc, they will be stored separately in the database, so if you have to translate a new line, which is only partly different, like abd, then a and b will be found in the database and translated while only d will stay untranslated until you do it (that's the case for other separators as well, like lists a|b|c|d).
If I do the change you request, abd will become ab, which is neither an empty line, nor will it be obvious, that something is missing at all.

What you could try for new lines is saving them as DB, filter the empty lines, translate them and append them to your MT.


Well, I'm also known as "TheWonderer"

Do you think that adding the database aligning style into the MT file won't cause any offset when generating a new MT?

 

[Sargon]

I don't think there will be a problem, the order of the input file is quite irrelevant, as long as the columns match the header.

 

[dolorosa]

Well, you can use your original translation file and everything should be where it's supposed to be.
Theoretically you could translate "Как дела?" in how many different ways you want, wherever you want.
But no warranty

Hi. I come in here with another question, and which turns out to be a problem for all the languages which's grammar have genders. As you know, and as I understood, the tool itself picks an unique text string (in case of doubles) and implements it (like it was in "Как дела?" case). In other words, it imports the unique string based on what's in the the source language side. In the English language's case, that would work just fine, but that is because English nouns have no gender(unless you're referring to a woman or a man, that is an example). My language does. I will come up with an example. If you say :'Конечно, бери его.'- that could refer to a 'weapon' which in my language is feminine( Sigur, ia-o), but, let's say we're talking about an elixir which in my language is masculine( Sigur, ia-l). That is bad. The program imports this text, and one of them will be faulty, because you can't say: 'Sigur, ia-o' when you're referring to an elixir, or 'Sigur ia-l' when you're referring to a weapon. Could anything be made to lessen this 'error'?

 

[Sargon]

If there is only one phrase for taking all kinds of items, you'll have to translate it in a way that would be acceptable for all items in your language.
If you want additional phrases for different circumstances, you would have to change the code of the mod accordingly, not much can be done on the translation side.

 

[zuzmii]

Hello all!

Dear Sargon! I've done a lot of research, also on the worldofplayers forum, and I found that you are the only person who has a lot of experience in extracting text files in the game. I would like to make a new English (later maybe Hungarian) translation for the game, so I need a method to extract the latest texts of the current build (December 2021 - Gothic 2 Returning - New Balance) from the game and then re- import it.

Your program would be extremely useful to me, but I would like to do something a bit different. Is there any way I can see the source code for your 'Easy Gothic Mod Translator' program? Is it up on github or somehere maybe?

The only thing I don't understand is how you export the game texts from the 'AB_Scripts.vdf' file to string form. I couldn't find a solution to this issue.

I would love to spend time solving this problem, but all the information is in Russian or German, which I don't understand at all.

edit:

If you can't / don't want to give me the opportunity to see your source code, you can just describe the method and I'll write my own script to do the job. One thing I need is a method to access all the raw Russian strings of the game (base game + ret + new balance) and import them back. I will do the rest.

 

[Sargon]

Sorry, I can't give you the source, you wouldn't make much sense of my spaghetti-code anyway
What would you like to do different?

The 1st step is extracting Gothic.dat, Menu.dat and OU.bin from the vdf-file.
You can do that with the GothicVDFS tool (the source can be found here, ©NicoDE)
I don't know how much prior knowledge you have, but the dat-files are the compiled scripts and in the ou.bin you can find the subtitles.
If you examine them with a hex-editor you'll see that every text line can be identified by preceding code sequences, which you can use to extract them, but you won't have the context (what kind of string).
In Gothic scripts system strings and text strings are mixed up, so in general there is no easy or flawless way to extract translateable text automatically,
but russian text can be identified quite easily, because the chars have all ascii code >128.
You can either extract and reinsert text this way, or you can decompile the scripts and try to get context for the strings, which is very complicated.
The inner structure of a dat-file looks like this, and an example decompiler with source can be found here.

 

[zuzmii]

Thanks for your help! I finally managed to export two CSV files from AB_Scripts.vdf using your program, but unfortunately it won't work as I wanted.

In a nutshell, what I wanted to do is to use the API of the DeepL translation site instead of Google's translation API, because it can do a miles better quality translation job. The problem was that DeepL's API is a paid service that requires a credit card registration, after which you can get 500,000 characters translated with it (although DeepL Translate: The world's most accurate translator is completely free, but the api is not... that's weird). I counted 4,155,635 characters in the first CSV file alone, so unfortunately there's no chance of this working. Anyway, it was fun to scan a csv file with nodejs, because so far I've only done it with java

I am sad

 

[Slavemaster]

(although DeepL Translate: The world's most accurate translator is completely free, but the api is not... that's weird)

It is not weird. Wanna convinient way to translate a lot of text - pay the money.
In the other case you can automate a browser with Selenium WebDriver.
Or maybe it is possible to hack their API like it is done for Google Translate.

And is that DeepL really so good?