Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[leeamstrong]

Hey. Is it possible, using dfhack, to change the lines that are displayed on the screen? I want to translate the game into another language.

[Putnam]

It involves binary patching, so it's a bit less compatible than DFHack and I'm not entirely sure it's compatible with DFHack.

[lethosor]

Sorry, missed this post originally. Binary patching is not the only way - it is possible to do with DFHack and without binary patching, although not well. For instance, there's a Russian translation which (from what I remember) relies on Truetype being turned on, then intercepts calls to Truetype drawing functions to replace text on the fly. This requires a Truetype font with Russian characters, though, and Truetype in general doesn't work very well (and isn't reliably supported everywhere in DF).

Another option is to search for text on the screen and translate it, ideally between when the screen is drawn and when it is displayed. This would probably be slow and unreliable at best, though.

To answer your question: technically yes, but it would take an awful lot of work to get it to work correctly/reliably.

Regarding binary patches: DFHack is compatible with patched DF binaries, although it requires changing symbols.xml on non-Windows. But binary patches are a worse solution, if you ask me, because they can't account for situations where the same string (or even part of one) is used differently in different places.

[Quietust]

But binary patches are a worse solution, if you ask me, because they can't account for situations where the same string (or even part of one) is used differently in different places.

And that's just on Windows, where all the compiler does is string pooling - on Linux, the compiler even merges substrings together (e.g. the string "courage" is internally stored and referenced as the last 7 characters of "encourage").

[mifki]

Another option is to search for text on the screen and translate it, ideally between when the screen is drawn and when it is displayed. This would probably be slow and unreliable at best, though.

I actually thought of this after seeing another localisation-related topic before reading it. I think this IS the best approach. There are not so many screens requiring translation, and the location of text on them is known too. Rendering of these screens can be intercepted, and text replaced - either with other predefined text or translating on-the-fly, or combination of both.

Look at a proof of concept I made - it translates text screens using Google Translate API (colours are lost at the moment, I know). Interestingly, the latest version of it allows to define your own glossaries, so the translation can be greatly improved in our case (when all texts are composed of pre-defined elements).

[Warmist]

<...>

Ok my rational part is saying, oh nice it's just everything put together. My emotional is saying WTF how it this possible.

[lethosor]

Seems I overestimated the difficulty of that, as usual

I do expect screens where the text isn't as easily accessible to be harder to work with, though (edge cases include letters/keys in menus, abbreviated words - some of which are abbreviated dynamically, and names). I feel like my attempts at searching for text on other screens were a bit slow, but it can probably be improved by caching somewhere (and maybe that was in Lua - not really sure).

Languages with non-latin alphabets are another issue, of course (without Truetype/TWBT, anyway).

[mifki]

I feel like my attempts at searching for text on other screens were a bit slow, but it can probably be improved by caching somewhere (and maybe that was in Lua - not really sure).

What do you mean "searching for text"? Anyway, how I see it:

There's static text (basically, the UI), semi-static (with a known set of options, like the embark location properties) and fully dynamic (announcements, text screens, mission reports, merchant responses, etc.). The first two can be done with a simple string replacement, I think there should be a file specifying original string, original string screen position (OR an approximate rectangle), and a new string. A plugin then would check that text in the specified location matches the given string and replace it.

Dynamic text requires on-the-fly translation and special handling in each case, but there's too many of such screens.

Other things to consider is what can be translated in raws, what to do with the names, and what can be left untranslated.

[lethosor]

Yeah, I was assuming the position of text wouldn't be hardcoded, since some of it can move around, particularly with DF updates. Avoiding the need to verify the positions of every string after every DF update would be nice.

Raws are interesting. I would think nearly everything in English (e.g. plant names) could be translated to some extent, but there's not much point in translating Dwarven.

[mifki]

Yeah, I was assuming the position of text wouldn't be hardcoded, since some of it can move around, particularly with DF updates. Avoiding the need to verify the positions of every string after every DF update would be nice.

First, it can be automated, at least if a string not found in a place it should be, it can be highlighted and a message logged. Most of the screens hardly ever change. Second, it's about providing a toolset for localisation, I'm pretty sure people who want to do the actual translation wouldn't mind keeping track of screen locations if that's the way to do it. Again, the locations don't have to be exact. For example, on the military screen there is some text/commands at the top-left, then lists in the middle, and more commands at the bottom-left. So only the top and bottom rectangular areas should be defined along with any strings that may appear there and their translations.