Translating the TDM GUI

[ECHELON]

Yes, I would agree with you. But if the old method isn't sustainable, then what is the point of translating the inventory? There is not going to be any way to automate the translation of briefings and objectives, which are the major barrier to playing a mission. If a player can't understand the objectives, what difference does it make if they know what kind of key they have?

 

To me it seems like lowering the door-handle so someone in a wheelchair can reach it, when the door is at the top of a flight of stairs. Maybe I'm missing something.

 

Unfortunately you are absolutely right. : /

 

we could partially resolve the problem with the method I suggested above, that is "copying" the installation method of the missions in Thief 2.

For example, in the folder xdata of FM, there will be 4-5 folders, such as Italian, English, German, Spanish etc. ...

When you go to install, should come out a drop down menu to select the language, and the dark mod shall take the corresponding file from the folder.

Like, if I choose italian, it goes in italian folder goes and takes file.xd.

 

In this way you will have only one package (and link) of the mission.

 

But still the problem of updating the translation of the fans if the upgrade mission, but this seems like a minor problem, in my opinion.

 

I do not know if I have explained.

[Tels]

Yes, I would agree with you. But if the old method isn't sustainable, then what is the point of translating the inventory? There is not going to be any way to automate the translation of briefings and objectives, which are the major barrier to playing a mission. If a player can't understand the objectives, what difference does it make if they know what kind of key they have?

 

Uh, I think you have it backwards. Of COURSE we will translate the objectives, readables etc. But we do this _later_. Right now I care for:

 

* the inventory and

* the code support to do so

 

Both need to be in place and working before somebody else can tackle the other problem. That you get translated names for keys is just a side-effect. (and a nice one, too, because it makes the work of other guys later easier)

 

To me it seems like lowering the door-handle so someone in a wheelchair can reach it, when the door is at the top of a flight of stairs. Maybe I'm missing something.

 

Probably that when the lift is working, the gui would still not be able to get through the door because the handle is to high - and right now there is a gui there who can lower door handles, but the lift is installed later by someone else. And that somebody else doesn't need to lower the door handle, because that is alreay done.

 

In the end, wheelchair driver is happy.

 

(*groan at analogy* At least it wasn't a car one...)

[ECHELON]

Why no one reads my proposals?

[Tels]

Why no one reads my proposals?

 

Because I am busy building a system which is even better

 

Anyway, the code is 90% done, so please be patient, I will post when it is done. But not before (at least I think I learned this lesson

[Tels]

Okay, the code's finally done, more or less. The following issues should now be fixed:

 

• Font loading does not fall back to English
  
• Add support for FM specific translations
  
• Support FM short descriptions in other languages
  
• sys_lang only allows a fixed set of languages
  

 

Here is a short overview on what is possible/working now:

 

* switching the language is no longer restricted to what D3 allows, you can switch f.i. to Portuguese now

* language switches do no longer require a restart (the GUI currently flicks back to the Video Settings page, this will be fixed shortly - fixed, except the switch between Russian/English requires a restart, this needs automating it)

* Polish uses the English fonts (and this is possible for other languages that we add later, too). This way we don't need an extra copy of all fonts just for Polish.

* FMs can have their own, specific dictionaries under "strings/fm/[LANGUAGE].lang", using string ids from 20000 to 89999. This means you can put each string for an FM into this file, so further translations/changes of the FM do not need to touch the FM PK4 package. It is even possible to pack the director "strings/fm" into an extra PK4 file, so this can be updated later.

* FMs can also override the default strings. So if an FM wants to replace "New Mission" with "Start the Heist", it can

* FM translations fall automatically back to English if the string is not in the selected language. So if you have "#str_20000" "House" in an FM, but no Spanish version of that (because it was simply not yet done), you get the English version of this.

* FM titles and description in darkmod.txt can use "#str_20000" etc. so they are translatable, too

* The code that moves articles to the back ("A House" => "House, A") also works in other languages now (is not yet complete, but covers German, Dutch, French, Italian, Spanish and a few cases of others languages).

 

What does not work yet:

 

* GUI switch is not quite right, should land in Video General settings again. Fixed

* Swithcing between English/Russian does not reload the font. Probably requires a forced restart of the game.

* the code that installs/uninstalls an FM should also look for an "[fmpk4name]_i18n.pk4" package (e.g. "training.pk4" and "training_i18n.pk4") and install/uninstall it alongside it. Likewise for downloading missions. That way the translation can live it is own file, and the user does not need to manually download/move/update that file.

 

Screenshots to prove it:

 

 

In the last screen you see an entity that has set:

 

"inv_name"  "#str_200000"

 

and with a dictionary of strings/fm/german.lang:

 

{
       "#str_20000"        "Mein Schlüssel FM"
}

 

Started this article: http://wiki.thedarkmod.com/index.php?title=I18N (more will follow later)

 

Edit: In case someone is interested in the technical details:

 

The new CVAR tdm_lang is bound to the menu setting. Every time D3/TDM starts, as well every time this variable changes, a callback to the SDK is made.

 

There is a new I18N object, which stores the current language, provides utility functions (like translate a string, reverse-translate it from english to #str_00000 ID, ore move the article back).

 

This object also does some dirty tricks with the D3 CVAR (setting it either to the language you want, or to english in case of polish so the font loading works correctly). Oh, and it "fixes" the system dict by clearing it, then loading the new language into it, then adding the FM specific overrides, including their English fallback. The trick here is that although we get a const ptr to the system dict object, this is merely a compiler convention that says "do not modify that". Once we cast the pointer, we can modify the object by calling f.i. Clear() or Load() on it. Sneaky, but works

 

So in the end D3 thinks you are running english, but everything is correctly translated into the current language, depending on FM

[ECHELON]

Assuming that in my opinion this system will double the work that "we" FM translators should do, i don't understand HOW to translate anything.

Edited August 6, 2011 by ECHELON

[Tels]

Assuming that in my opinion this system will double the work that "we" FM translators should do, i don't understand HOW to translate anything.

 

Er, no, the system does not double the amount of work

 

Here is how the old system works:

 

* the FM is produced in English

* Someone modifies the FM and translates it to German

* Someone modifies the FM and translates it to French

* Someone modifies the FM and translates it to Spanish

* ...

* Author updates FM, all translations are now outdated

 

(The old system is of course still avaiable, if someone wants it badly)

 

The new system is either:

 

Old FM existing:

 

* the FM is modified once to use "#str_2xxxx" strings instead of English text, all the texts are moved to an external file (I will gladly help with this if this helps. I think it might also be automated with the help of a script.)

* Only the external file is translated to German (FM left alone)

* Only the external file is translated to Spanish (FM left alone)

* Only the external file is translated to French (FM left alone)

* ...

* Author updates FM, all translations are still working, except a few things that are maybe new and need to be translated (like added entities, street signs etc)

 

New FM:

 

* the FM is build with "#str_2xxxxx" strings instead of English text, all the texts are stored in an external file

* Only the external file is translated to German (FM left alone)

* Only the external file is translated to Spanish (FM left alone)

* Only the external file is translated to French (FM left alone)

 

So it is, from the POV of a translator, exactly the same work as before, except that it is easier to modify the translation, because you don't have to touch the FM itself. From the POV of a mission author, it is not more complicated, just a bit different.

 

Once a usable package is build, I can make a small demo mission to show you. I will also document the entire process on the wiki (just give me some time to finish my work, okay?)

[ECHELON]

Ok, now is more clear.

 

In any case I was right: the work now is twice, only that the translator makes the middle and the creator of maps the other half.

 

--------

 

However, another problem arises: if I now want to translate a Fan mission already left, I have to wait for the creator to change it. And this also means that if the creator type connects once every 3-4 months for commitment, I should wait AT LEAST 3-4 months to translate the mission (if the creator connects...).

 

Another problem: since the translations of the FM must be contained in the file tdm_x_lang_test, to distribute to each italian translation, I should wait to be released "officially" the file via tdm_updater etc. ....

 

Try to imagine that 4 translators of 4 different languages translate consecutively a lot of FMs:

should be released a version of tdm_x_lang_test almost daily ...

 

Finally, ask the case that I've made ​​a mistake in a FM: should I send the files and should be out of the umpteenth release tdm_x_lang_test.

 

Probably I'm wrong, but more likely I am right.

[Tels]

Ok, now is more clear.

 

In any case I was right: the work now is twice, only that the translator makes the middle and the creator of maps the other half.

 

--------

 

However, another problem arises: if I now want to translate a Fan mission already left, I have to wait for the creator to change it. And this also means that if the creator type connects once every 3-4 months for commitment, I should wait AT LEAST 3-4 months to translate the mission (if the creator connects...).

 

No, not really, nobody stops you from modifying the FM right now. After all, you do that with the normal translation right now, anyway

 

Another problem: since the translations of the FM must be contained in the file tdm_x_lang_test, to distribute to each italian translation, I should wait to be released "officially" the file via tdm_updater etc. ....

 

No, not really. I admit the official updater is not yet updated to deal with these cases, but once it is, this will be easier. Anyway, you can upload a FM .PK4 file and an itialian .PK4 file, right now.

 

Or do you mean that the current work on translations I did is only available in v1.07? That is right, and I am sorry, but that is nothing I can change. (I am not sure what the critism here is. That I didn't all that work 3 years ago? Oh sorry, I wish I had, but there are always 200% of things occupying my spare time

 

Try to imagine that 4 translators of 4 different languages translate consecutively a lot of FMs:

should be released a version of tdm_x_lang_test almost daily ...

 

Given that fact that we have about 45 missions, but only overall 6 or so translations (where we actually should have 45 * 5), I don't think this will be an issue. It would be cool if multiple translators worked on one FM, but I think you can just forget this

 

Edit: OH I think misunderstand me. tdm_x_lang_test.pk4 is just for testing that things work. The real translations will live in sep. files, one for each FM.

 

Finally, ask the case that I've made ​​a mistake in a FM: should I send the files and should be out of the umpteenth release tdm_x_lang_test.

 

Probably I'm wrong, but more likely I am right.

 

I do think you overestimate how often FMs are updated. Most FMs are never upated, or only once after a year or so. Some FMs are updated 3 times right after release (because the beta test period was too short), but even in this case you can just wait 2 weeks after a release and then provide the translation.

 

Also, it would be no problem to make a new SVN repository. Translators could just check in their translation files into that repository.

 

(that what SVN is for, multiple people working on the same set of files)

 

Then once a week we can pull the latest translation for the FMs from their, build a set of PK4 files and push it to the website. The in-game downloader than tells users they have updates there.

 

In short, I think this are all non-issues, or issues that can be solved by automating things.

 

And in any event, this is MUCH better than the current way, where each translator has to modify each FM on their own.

[ECHELON]

No, not really, nobody stops you from modifying the FM right now.

 

 

In fact, with the "standard" translation there is no such problem. with the kind of translation will be done instead yes.

 

After all, you do that with the normal translation right now, anyway

 

??? (rewrite the sentence in another way that I don't understand)

 

I do think you overestimate how often FMs are updated. Most FMs are never upated, or only once after a year or so. Some FMs are updated 3 times right after release (because the beta test period was too short), but even in this case you can just wait 2 weeks after a release and then provide the translation.

 

Also, it would be no problem to make a new SVN repository. Translators could just check in their translation files into that repository.

 

(that what SVN is for, multiple people working on the same set of files)

 

Then once a week we can pull the latest translation for the FMs from their, build a set of PK4 files and push it to the website. The in-game downloader than tells users they have updates there.

 

In short, I think this are all non-issues, or issues that can be solved by automating things.

 

And in any event, this is MUCH better than the current way, where each translator has to modify each FM on their own.

 

No, You misunderstand me. I mean with errors (and updates) of translation, no of the mission.

 

 

In any case I ask you a question to see if I understand correctly.

For example, after that will exit the 1.07, and I do 5 translations (3-days apart from each other), after they leave?

Every week? Every month?

Every year? LOL

Edited August 7, 2011 by ECHELON

[Tels]

In fact, with the "standard" translation there is no such problem. with the kind of translation will be done instead yes.

 

 

 

??? (rewrite the sentence in another way that I don't understand)

 

 

 

No, You misunderstand me. I mean with errors (and updates) of translation, no of the mission.

 

Sorry, I am a bit unsure what exactly we are talking here

 

I meant:

 

* old scheme: you can do modify an FM right now - just copy it, modify it in Italian, be done.

* new scheme: you can do modify+translate an existing FM with the new scheme, right now, too. Just modify the FM (as I said, I will write a script which will probably to 90% automate this), then translate the strings/fm/english.lang into strings/fm/italian.lang. The only catch is that nobody can play this FM until we release v1.07.

 

In any case I ask you a question to see if I understand correctly.

For example, after that will exit the 1.07, and I do 5 translations (3-days apart from each other), after they leave?

Every week? Every month?

Every year? LOL

 

Sorry, I do not understand this at all.

[ECHELON]

Sorry, I am a bit unsure what exactly we are talking here

 

I meant:

 

* old scheme: you can do modify an FM right now - just copy it, modify it in Italian, be done.

* new scheme: you can do modify+translate an existing FM with the new scheme, right now, too. Just modify the FM (as I said, I will write a script which will probably to 90% automate this), then translate the strings/fm/english.lang into strings/fm/italian.lang. The only catch is that nobody can play this FM until we release v1.07.

 

 

 

Mmm... I had understood that the mission creator had to do the process of converting for example "stop quintus" in "str_#20000", and not me. So i had to do converting and translating, right?

Edited August 8, 2011 by ECHELON

[Tels]

Mmm... I had understood that the mission creator had to do the process of converting for example "stop quintus" in "str_#20000", and not me. So i had to do converting and translating, right?

 

It depends. If its an old mission and the creator not longer available (or just doesn't care), you have to do it. Or find somebody to do it for you

 

Btw, as I said "it can be scripted", I think that at least 90% of that work can indeed be done with a script. The map file is just a text file, with a bit of Perl magic I can produce the dictionary and a modified map.

 

Please give me a few days to whip up a proof of concept

[ECHELON]

It depends. If its an old mission and the creator not longer available (or just doesn't care), you have to do it. Or find somebody to do it for you

 

Btw, as I said "it can be scripted", I think that at least 90% of that work can indeed be done with a script. The map file is just a text file, with a bit of Perl magic I can produce the dictionary and a modified map.

 

Please give me a few days to whip up a proof of concept

 

Ok, NOW is more clear...

 

However, the two think i don't understand are:

 

-with this method are also translated the objectives, books, briefings, etc.?

 

-I really think whith this method i can not translate the maps / images. am I right?

Edited August 8, 2011 by ECHELON

[Tels]

Ok, NOW is more clear...

 

However, the two think i don't understand are:

 

-with this method are also translated the objectives, books, briefings, etc.?

 

They would be translated with the same method, but I admit I have not tried if this really works everywhere. (I guess it will, as D3 used the technique to translate every string).

 

-I really think whit this method i can not translate the maps / images. am I right?

 

I don't think so. If the image/map/whatever contains a "painted on" text, it cannot be translated. Not sure if "#str_12345" will work as a path in a texture, but I guess not. The only method that probably works is creating another "mymission_german.pk4" file which contains a replacement map/image/texture.

 

Of course, that then poses the problem that the TDM also must copy around this file *sigh* I wish that translation stuff was over already..

[Springheel]

Mmm... I had understood that the mission creator had to do the process of converting for example "stop quintus" in "str_#20000", and not me. So i had to do converting and translating, right?

 

You definitely shouldn't modify a mapper's pk4 file without getting their permission first.

[ECHELON]

You definitely shouldn't modify a mapper's pk4 file without getting their permission first.

 

I had forgotten about this particular well.

[Tels]

You definitely shouldn't modify a mapper's pk4 file without getting their permission first.

 

That's why I was arguing that we need an open license like "creative commons" for all missions that TDM hosts. Now we have painted us in a corner where we host and distribute missions that we can't even bloody translate just because the author died, is ill, no longer has a computer, or doesn't care - or simply things that nobody needs an Italian version, anyway *sigh*

 

Never mind the case we modify the PK4s to fix a bug. Oh wait, we already had that situation. What did we do back then? (I think we never modified the PK4s because we released a new version, but what if that is not possible)

 

So do you think the mappers needs to be asked first before a translation is made, too?`Or just in case a translation is made by modifying the PK4 file?

 

(If this goes off-topic about licenses we should split that up into a new thread please)

[Springheel]

Any modification to a mapper's mission should be preceded by an attempt to get their permission, IMO.

 

If the map is years old and the mapper can't be contacted, then that's a different matter. And if the original pk4 isn't being altered, but just a foreign-language version is being released, I doubt that would be a problem either.

 

But a mapper that's still around might have plans for their map in the future, like adding it to a campaign, or updating it to take advantage of new features like relighting.

[Tels]

Any modification to a mapper's mission should be preceded by an attempt to get their permission, IMO.

 

If the map is years old and the mapper can't be contacted, then that's a different matter. And if the original pk4 isn't being altered, but just a foreign-language version is being released, I doubt that would be a problem either.

 

But a mapper that's still around might have plans for their map in the future, like adding it to a campaign, or updating it to take advantage of new features like relighting.

 

Hm, ok, this is the "sensible approach", e.g. ask nicely, and if they don't respond, or work together, proceed anyway. I'd do it that way, too.

 

What got me worried is that you mean that "no modification can take way w/o the mappers consent". E.g. if we apply copyright law, then f.i. any translation is forbidden, unless the license allows it (or, the mapper allows it by granting you a specific license).

 

Which is why it is important that we ask mappers (strongly) to release their work under an open license, so that such unclear situations do not even arise.

 

(Just consider what would be if you had to ask Oddity now if you could change/use one of his models...)

[Tels]

Just a small update. The past days I wasn't lazy, but I did not actually accomplish much (in terms of nea features or progress).

 

* The I18N object I wrote turned out to not work under Windows (crashed, thanx grayman for testing!), so I had to completely rewrite the beast, this time using source hooks. Now it works stable, on both Linux and Windows. Yeah. Lot's of work to accomplish more or less nothing new...

* Also, Fidcal reported that old configs with values like "inventory_use Lantern" would no longer work, so I extended the reverse-translation support to cover these and added a bit of code to make it work transparently.

* And while trying to figure out why multiline inventory names did not work for ECHOLON, it came to light that if you have a dictionary with "First Line\nSecond Line", this works fine (there is a newline in the string), but if you have a spawnarg with the same value (set inside DR), it contains literally \n (aka "\\n"), and thus now newline and thus does not do what is expected. A bit of code magic later this works now for inventory names and categories, although it might be a problem in other cases. However, since from v1.07 on mappers should not used hard-coded inside their missions, instead put them into an FM specific dictionary, this isn't that much of a problem. Fixed it nevertheless.

 

So, lots of work done, but not gotten further...

 

Hopefully now I can care for the accented characters in our menu font

[Tels]

Progress report: Added an fm_translate.pl script to our SVN repository. It accepts multiple FM PK4 files as parameters in their different languages like so:

 

perl devel/fm_translate.pl --english fms/outpost/outpost.pk4 --french fms/avant_poste.pk4

 

From these files it parses the .map files, as well as the darkmod.txt files. It then extracts strings that need to be translated, and checks them agains the core dictionary. If they do not exist, it allocates new strings (#str_20000 and up). It also cross-references the languages and matches their strings.

 

The result is one or more (in the case above: two) FM dictionary files. In the case above the output is:

 

fm_translate.pl v0.01 - The Dark Mod Fan Mission translation helper.

Read 651 entries from strings/english.lang.
Found maps/outpost.map in fms/outpost/outpost.pk4, 1448873 bytes.
Found darkmod.txt in fms/outpost/outpost.pk4, 109 bytes.
Found maps/outpost.map in fms/avant_poste.pk4, 1449007 bytes.
Found darkmod.txt in fms/avant_poste.pk4, 132 bytes.
Parsing darkmod.txt for french.
Parsing darkmod.txt for english.
Created '#str_20000' for 'The Outpost'
Created '#str_20001' for 'Break into a builder outpost to retrieve a gold ingot.'

Found 533 entities.
Found 533 entities.
Matched 'Normal' to #str_03005 (base)
Matched 'Hard' to #str_03012 (base)
Matched 'Master' to #str_03008 (base)
Matched 'Chest Key' to #str_10028 (base)
Created '#str_20002' for 'Gold Ingot'
Created '#str_20003' for 'Loot'
Created '#str_20004' for 'Leave the outpost after your main objectives are done and get back to the front gates.'
Created '#str_20005' for 'You won't find bags full of money in a builder outpost, but take away any valuables you can get hold of. Find valuables worth at least 600.'
Created '#str_20006' for 'You won't find bags full of money in a builder outpost, but take away any valuables you can get hold of. Find valuables worth at least 700.'
Created '#str_20007' for 'No knock outs too.'
Created '#str_20008' for 'Killing is not your style. No corpses tonight.'
Created '#str_20009' for 'You won't find bags full of money in a builder outpost, but take away any valuables you can get hold of. Find valuables worth at least 800.'
Created '#str_20010' for 'The massive gold ingot should be worth a fair amount of money. Find out where the ingot is kept and change its ownership.'
Gathered 11 FM specific strings.
Writing output/strings/fm/french.lang ... 11 entries, done.
Writing output/strings/fm/english.lang ... 11 entries, done.

All done. Took 0 seconds.

 

And here are the dictionaries:

 

// String table english (iso-8859-1)

// This file was generated automatically on 2011-08-20 12:53 UTC by fm_translate.pl v0.01

{
       "#str_20000"    "The Outpost"
       "#str_20001"    "Break into a builder outpost to retrieve a gold ingot."
       "#str_20002"    "Gold Ingot"
       "#str_20003"    "Loot"
       "#str_20004"    "Leave the outpost after your main objectives are done and get back to the front gates."
       "#str_20005"    "You won't find bags full of money in a builder outpost, but take away any valuables you can get hold of. Find valuables worth at least 600."
       "#str_20006"    "You won't find bags full of money in a builder outpost, but take away any valuables you can get hold of. Find valuables worth at least 700."
       "#str_20007"    "No knock outs too."
       "#str_20008"    "Killing is not your style. No corpses tonight."
       "#str_20009"    "You won't find bags full of money in a builder outpost, but take away any valuables you can get hold of. Find valuables worth at least 800."
       "#str_20010"    "The massive gold ingot should be worth a fair amount of money. Find out where the ingot is kept and change its ownership."
}

 

// String table french (iso-8859-1)

// This file was generated automatically on 2011-08-20 12:53 UTC by fm_translate.pl v0.01

{
       "#str_20000"    "L'avant-poste"
       "#str_20001"    "Introduisez-vous dans un avant-poste du Createur et volez-y un lingot d'or."
       "#str_20002"    "Lingot d'or"
       "#str_20003"    "Loot"
       "#str_20004"    "Une fois vos objectifs remplis, quittez l'avant-poste et retournez a la porte principale."
       "#str_20005"    "Vous ne trouverez pas de sacs pleins d'or dans un avant-poste du Createur, mais emportez tous les objets de valeur que vous trouverez, pour une valeur d'au moins 600."
       "#str_20006"    "Vous ne trouverez pas de sacs pleins d'or dans un avant-poste du Createur, mais emportez tous les objets de valeur que vous trouverez, pour une valeur d'au moins 700."
       "#str_20007"    "D'ailleurs vous n'aimez pas assommer les gens non plus."
       "#str_20008"    "Vous n'etes pas du genre a tuer. Pas de cadavres cette nuit."
       "#str_20009"    "Vous ne trouverez pas de sacs pleins d'or dans un avant-poste du Createur, mais emportez tous les objets de valeur que vous trouverez, pour une valeur d'au moins 800."
       "#str_20010"    "Le lingot d'or devrait valoir pas mal d'argent. Trouvez ou il est cache, et faites-le changer de proprietaire."
}

 

 

What it doesn't do currently is creating a new PK4 file with the modified "darkmod.txt" and "outpost.map" file in it. But that's not that hard, I just did run out of time for today. Stay tuned

 

Edit: It incorrectly did not skip "Loot" as inv_category. This has been since fixed.

[nbohr1more]

Great work Tels!

 

Now we will need multilingual versions of our Moddb presence (etc)... (yikes... and the TDM home page )

 

Unless there are other places where non-english speakers prefer to go to discover mods...

 

[grayman]

I brought up the readables editor today for the first time since internationalization was begun, and I noticed that the inventory_name defaults to "#str_02495".

 

What should I be doing with that? Can I change it to the actual English inventory name, or am I supposed to be supplying a mapping somewhere from "#str_*" to the actual string?

[ECHELON]

Here's the translated strings:

 

"#str_20000" "L'Avamposto"

"#str_20001" "Irrompi in un'avamposto hammerita per prendere un lingotto d'oro."

"#str_20002" "Lingotto d'Oro"

"#str_20003" "Bottino"

"#str_20004" "Lascia l'avamposto dopo aver completato i tuoi obiettivi e torna al cancello principale."

"#str_20005" "Non troverai borse piene di denaro in un avamposto hammerita, ma puoi benissimo prendere tutti gli oggetti di valore che riesci a trovare. Prendi almeno 600 di bottino."

"#str_20006" "Non troverai borse piene di denaro in un avamposto hammerita, ma puoi benissimo prendere tutti gli oggetti di valore che riesci a trovare. Prendi almeno 700 di bottino."

"#str_20007" "Non stordire nessuno."

"#str_20008" "Uccidere non e' il tuo stile. Non lasciare cadaveri questa notte."

"#str_20009" "Non troverai borse piene di denaro in un avamposto hammerita, ma puoi benissimo prendere tutti gli oggetti di valore che riesci a trovare. Prendi almeno 800 di bottino."

"#str_20010" "L'enorme lingotto dovrebbe valere un mucchio di soldi. Scopri dove si trova ed impossessatene."