So erstellst du einen Übersetzungspatch

Ein Übersetzungspatch ist keine Kopie eines Spiels. Er ist die Arbeit des Übersetzers — die Zeilen, dazu genug Information, um zu sagen, welche Zeile wohin gehört — in einer Form, die jemand anders auf seine eigene Kopie anwenden kann. Jeder Markt hat seinen eigenen Namen dafür: im Deutschen der Übersetzungspatch oder schlicht die Fanübersetzung, in Korea ein 한글패치, in Russland ein русификатор. Das Artefakt ist überall dasselbe, und die Arbeit, eines herzustellen, auch.

Zwei Arten von Patch, und die Weggabelung entscheidet alles

Bevor du irgendeinen Text anfasst, entscheide, welches der beiden Dinge du baust, denn fast jede spätere Entscheidung folgt daraus.

Ein Laufzeit-Overlay übersetzt, während das Spiel läuft. Etwas lädt sich neben dem Spiel — ein Plugin in der Engine, ein Text-Hook, der den Speicher des Spiels liest, oder eine Bildschirmerfassung, die Pixel liest —, fängt jede Zeile ab, kurz bevor sie gezeichnet wird, und setzt eine Übersetzung ein. Auf der Festplatte ändert sich am Spiel nichts. XUnity.AutoTranslator ist das bekannte Beispiel für Unity, und MTool arbeitet so für RPG Maker.

Ein gepatchtes Build legt die Übersetzung in die spieleigenen Dateien. Der Text wird aus den Daten gelesen, die die Engine tatsächlich lädt, übersetzt, zurückgeschrieben, und das Ergebnis ist ein Spielordner, der für sich allein startet und läuft, ohne dass etwas daneben läuft. Das ist es, was RuneTranslate herstellt, und was Translator++ auf den Engines herstellt, die es zerlegt.

Der ehrliche Handel, nüchtern gesagt:

• Ein Overlay braucht keine Arbeit pro Spiel — es hookt die Engine oder eben nicht —, aber nichts wird gesichert. Jede Zeile wird bei jedem Durchgang neu übersetzt, auf jedem Rechner, und jeder Spieler muss das Overlay selbst installieren und einrichten.
• Ein Overlay erreicht Text nur in dem Moment, in dem er gezeichnet wird. In Grafiken eingebrannter Text, Text, der nie durch die gehookte Komponente läuft, und Text, den ein eigener Renderer zeichnet, bleiben unübersetzt.
• Ein gepatchtes Build kostet dich einen Export-Schritt und einen Testdurchlauf, und es muss wiederholt werden, wenn das Spiel aktualisiert wird. Was du dafür bekommst, ist dauerhaft: Die Datei hält die Übersetzung, das Spiel ist also übersetzt, offline, für jeden, der deine Arbeit anwendet.
• Ein gepatchtes Build gibt dir eine bearbeitbare Aufzeichnung. Du kannst eine schlechte Zeile ein halbes Jahr später korrigieren, ohne alles andere neu zu übersetzen — bei einem Overlay gibt es nichts zu korrigieren, nur einen Cache zu leeren.

Übersetzt du für dich selbst, einmalig, auf einer Engine, die sich nicht zerlegen lässt, ist ein Overlay eine vernünftige Antwort, und daran ist nichts verkehrt. Willst du deine Arbeit an andere Leute weitergeben, willst du ein gepatchtes Build — denn ein Patch ist nur dann teilbar, wenn er als Datei existiert.

Was du vorher brauchst

• Eine Kopie des Spiels, die dir gehört, installiert und spielbar. Spiel es zuerst ein paar Minuten — du kannst nicht beurteilen, ob sich eine Übersetzung richtig liest, wenn du den Kontext nie gesehen hast.
• Das Wissen, welche Engine es nutzt. Davon hängt alles ab, wie der Text herauskommt und wieder hineingeht.
• Eine Zielsprache, die du tatsächlich liest. Maschinelle Übersetzung liefert dir einen Entwurf; sie liefert dir keinen Patch.
• Speicherplatz für eine zweite Kopie des Spiels. Ein gepatchtes Build ist ein eigener Ordner — dein Original wird nie verändert.

Die Engine zu bestimmen ist meist eine Sache des Blicks in den Spielordner. Ein www/data- oder data-Ordner voller JSON-Dateien ist RPG Maker MV oder MZ; ein <Game>_Data-Ordner ist Unity; game/*.rpy oder .rpa-Archive sind Ren'Py; .xp3-Archive sind Kirikiri. Die vollständige Liste dessen, was sich zerlegen lässt, samt den Erkennungsmerkmalen, steht auf der Engines-Seite — RuneTranslate deckt 17 Engines und Formate ab, und die Erkennung läuft automatisch, sobald du auf den Ordner zeigst.

Der Ablauf

Unabhängig von der Engine sind es beim Patch-Bau dieselben fünf Schritte in derselben Reihenfolge. Die Versuchung ist, Schritt drei zu überspringen. Tu es nicht.

1. Extrahieren — jeden übersetzbaren String aus den spieleigenen Dateien in eine Liste holen, in der du arbeiten kannst.
2. Übersetzen — die Liste durch einen maschinellen Anbieter schicken, um einen vollständigen ersten Entwurf zu bekommen.
3. Prüfen — die Zeilen durchgehen, die eine Maschine verlässlich falsch macht: Namen, Anreden, Terminologie, alles mit einem Platzhalter darin.
4. Exportieren — die Übersetzungen zurück in das Format des Spiels schreiben und ein spielbares Build erzeugen.
5. Testen — dieses Build starten und tatsächlich spielen.

Extrahieren

Beim Extrahieren zahlt sich Engine-Wissen aus. Dialoge liegen selten in einer schlichten Textdatei: RPG Maker legt sie in Event-Befehlscodes ab, Unity in TextAsset-Nutzdaten und MonoBehaviour-Feldern in binären Asset-Dateien, Kirikiri in Skripten in einem verschlüsselten Archiv, Unreal in .locres-Tabellen in einer .pak. Ein guter Extraktor weiß auch, was er dir nicht geben darf — ein Szenenname, ein Variablenschlüssel, ein Vergleichsoperand und ein Asset-Pfad sehen alle wie Strings aus und brechen alle das Spiel, wenn sie übersetzt werden. In Grafiken gemalter Text ist ein eigenes Problem mit einem eigenen Werkzeug; siehe Bildübersetzung.

Übersetzen

Hol dir einen vollständigen maschinellen Entwurf, bevor du irgendetwas von Hand bearbeitest, damit du Text korrigierst statt auf eine leere Spalte zu starren. RuneTranslate liefert 9 Anbieter — Google, das kostenlose DeepL und DeepL Classic/Next-Gen brauchen gar keinen API-Schlüssel; DeepLs API, OpenAI, Anthropic Claude, DeepSeek, jeder OpenAI-kompatible Endpunkt und ein lokales Modell über Ollama oder LM Studio sind der Rest. Die kostenlose Stufe schaltet jeden davon und jede Engine frei; begrenzt werden der Durchsatz und das Halten von mehr als einem Projekt gleichzeitig. Welcher Anbieter zu welcher Art Spiel passt, behandelt der Anbieter-Vergleich.

Prüfen

Das ist der Schritt, der einen Patch wert macht, angewendet zu werden. Maschinenausgabe ist flüssig und selbstbewusst falsch an vorhersagbaren Stellen, arbeite diese Stellen also gezielt ab, statt alles von oben nach unten zu lesen:

• Figurennamen. Eine Maschine übersetzt sie jedes Mal anders, und manchmal übersetzt sie sie als Wörter. Lege die Schreibweise einmal fest.
• Anreden und Sprachebene. Ob -san / -chan bleiben oder wegfallen, ist eine projektweite Entscheidung, keine pro Zeile. Genauso, ob eine Figur förmlich spricht.
• Terminologie. Fertigkeiten, Gegenstände, Orte, Systeme, alles, was das Spiel erfunden hat. Eine Fertigkeit, die im Menü, im Tooltip und im Kampflog dreifach anders heißt, liest sich wie ein kaputtes Spiel.
• Platzhalter und Steuercodes. Alles wie \C[1], {player} oder [name] muss unversehrt überstehen. Ein übersetzter Platzhalter ist ein Absturz oder eine Lücke, kein Tippfehler.
• Zeilen, die unverändert zurückkamen. Meist Lautmalerei und meist ein Zeichen, dass der Anbieter bei dieser Zeile aufgegeben hat.

Konsistente Terminologie

Mehr Patches werden wegen Inkonsistenz aufgegeben als wegen schlechter Prosa. Spieler verzeihen einen steifen Satz; sie verzeihen nicht, dass dieselbe Figur in einem Gespräch Yuuki, Yuki und Schnee heißt, weil sie dann nicht mehr verfolgen können, wer spricht. Die Lösung ist ein Glossar: eine Liste von Quellbegriffen und dem exakten Zielbegriff, zu dem jeder werden muss, angewendet vor der Übersetzung, sodass der Anbieter gar nicht erst improvisieren kann. Bau es früh auf, aus den Namen, denen du in der ersten Stunde begegnest, und ergänze es unterwegs — der Glossar-Guide behandelt, wie es mit der Tag-Maskierung zusammenspielt und warum es an den Anfang gehört statt in einen Suchen-und-Ersetzen-Durchlauf am Ende.

Fonts

Ein japanisches Spiel liefert einen japanischen Font aus, und ein japanischer Font hat häufig keine Glyphen für Kyrillisch, Griechisch, Hangul, Thai oder die akzentuierten Buchstaben des Polnischen, Türkischen und Vietnamesischen. Übersetze in eine davon, und das Spiel zeigt leere Kästchen — die Übersetzung stimmt, der Font kann sie nur nicht zeichnen. Manche Engines sind für dich erledigt: Ein Ren'Py-Export bündelt einen fähigen Font und bildet die Fonts des Spiels darauf ab. Wo es nicht automatisch geht, hilft meist das Ersetzen der Font-Datei im exportierten Build. Buchstäbliche Fragezeichen sind ein völlig anderer Fehler — da verweigert die String-Kodierung der Engine ein Zeichen, es fehlt keine Glyphe — und die Unterscheidung lohnt sich, bevor du die falsche Lösung jagst. Beide Fälle behandelt die FAQ.

Das Build testen

Ein Export ohne Fehler ist kein getesteter Patch. Starte ihn und prüfe die Dinge, die still kaputtgehen:

• Das Spiel erreicht den Titelbildschirm und startet ein neues Spiel. Ein Build, das hier scheitert, ist meist an einer Zeile gescheitert, die nie Text war — an einem Bezeichner, der übersetzt wurde.
• Nachrichtenfenster halten ihren Text. Übersetzungen werden länger als das Japanische; achte auf Zeilen, die über den Rand laufen oder abgeschnitten werden.
• Menüs, Gegenstandsnamen und Tooltips — die Stellen, an denen ein langes Wort eine Schaltfläche fester Breite sprengt.
• Ein Speicherstand aus dem Originalspiel lädt weiterhin, und ein im gepatchten Build angelegter Speicherstand lädt ebenfalls.
• Eine Szene tief im Spiel, nicht nur der Anfang. Lücken beim Extrahieren zeigen sich als unübersetzte Strecken, nicht als Fehler.

Deine Arbeit weitergeben

Hier kommt der Teil, der entscheidet, ob dein Patch etwas ist, das du herausgeben kannst. Was du gemacht hast, ist die Übersetzung — die Zeilen. Das Spiel gehört nicht dir, und eine übersetzte Kopie davon zu packen heißt, das Spiel eines anderen zu verbreiten. Die ehrliche Form eines Patches ist die Arbeit allein, angewendet von jedem Empfänger auf eine Kopie, die er bereits besitzt.

RuneTranslate exportiert genau das als .rtpatch-Datei. Sie trägt die Unit-IDs, die Quellzeilen, auf die jede Übersetzung passt, und deine Übersetzungen. Keine Spieldateien, keine Assets, keine Binärdateien — die Datei ist dein Text und sonst nichts, weshalb sie klein genug ist, um sie an eine Nachricht zu hängen, und unbedenklich weiterzugeben.

Die Seite des Empfängers sind drei Schritte:

1. Er legt aus seiner eigenen installierten Kopie desselben Spiels ein Projekt an, wodurch auf seinem Rechner dieselben Zeilen extrahiert werden.
2. Er importiert deine .rtpatch, die diese Zeilen mit deinen Übersetzungen füllt.
3. Er exportiert sein eigenes spielbares Build aus seinen eigenen Spieldateien.

Zugeordnet wird zuerst über die Unit-ID, und ersatzweise über die Quellzeile selbst, wenn die IDs auseinandergelaufen sind — durch ein Spiel-Update oder eine Änderung im Extraktor. Dieser Rückfall ist es, was einen Patch nach einem Spiel-Update nutzbar hält. Der Import prüft, ob Engine und Zielsprache übereinstimmen, bevor irgendetwas angewendet wird, sodass ein Patch für ein Unity-Spiel nicht versehentlich in ein Ren'Py-Projekt fallen kann. Auf der kostenlosen Stufe ist das Teilen von Patches auf einen Export und einen Import pro rollierendem Drei-Tage-Fenster begrenzt; alles andere am Patch-Bau ist funktional ungedrosselt.

Dieselbe Datei ist auch, wie ein Team zusammenarbeitet — eine Person übersetzt die Story, eine andere die Menüs, und die Patches fließen in einem Projekt zusammen — und wie du deine eigene Arbeit behältst, wenn ein Spiel aktualisiert wird: aus der neuen Version neu extrahieren, deinen alten Patch importieren, und nur die Zeilen, die sich tatsächlich geändert haben, brauchen Aufmerksamkeit.

Ob ein Spiel selbst weiterverbreitet werden darf, entscheidet der Rechteinhaber, nicht du und nicht wir. Gib den Patch weiter, sag den Leuten, gegen welche Version des Spiels er gebaut wurde, und lass sie ihre eigene Kopie mitbringen.

Besonderheiten pro Engine

Alles oben ist die Form der Aufgabe. Was sich pro Engine unterscheidet, ist, wo der Text liegt, was der Export erzeugt und was außer Reichweite bleibt — und das liest sich besser vorher als nachdem ein Export dich überrascht hat: Unity, RPG Maker, Ren'Py oder die vollständige Engine-Liste für die anderen vierzehn.

RuneTranslate läuft unter Windows 10 und 11 sowie unter Linux und auf dem Steam Deck über Wine oder Proton. Beim ersten Start ist eine kostenlose Patreon-Anmeldung nötig; die kostenlose Stufe öffnet jede Engine und jeden Anbieter. Wenn du es gegen die Overlays und Toolkits abwägst, zu denen die meisten zuerst greifen, legen die Vergleiche dar, was jeder Ansatz dir tatsächlich gibt.