Wie man ein Videospiel mit KI übersetzt

Die Lokalisierung eines Spiels beginnt mit einer Datei, die Ihre Engine bereits für Sie erstellt hat. Die Aufgabe besteht darin, diese Datei an einen Ort zu senden, der sie genau so lesen kann. Unity bietet XLIFF oder CSV. Unreal bietet PO. Godot bietet beides. Keine dieser Dateien muss vorab umgeformt werden.

Dieser Guide ist die ausführliche Version: was Game-Lokalisierung tatsächlich beinhaltet, warum sie sich lohnt, welche Datei jede Engine ausgibt, was Sie je nach Dateiformat anfordern können und nicht, wie die Plattform heute einen Auftrag abwickelt und wie Sie den gesamten Loop an einen KI-Agenten übergeben, sodass ein Durchgang in zehn Sprachen eine einzige Entscheidung statt vierzig Klicks ist.

Was Game-Lokalisierung tatsächlich beinhaltet

Lokalisierung besteht aus vier separaten Aufgaben, die oft in einem einzigen Wort zusammengefasst werden. Zu wissen, in welcher Phase man sich befindet, erspart den meisten Ärger.

1. Internationalisierung, also Code, keine Sprache. Ihr Spiel muss überhaupt in der Lage sein, eine andere Sprache anzuzeigen: kein Text, der fest in eine Textur eingebettet ist, keine Sätze, die durch String-Konkatenierung zusammengesetzt werden, eine Schriftart mit den benötigten Glyphen und Layouts, die auch bei längeren Beschriftungen stabil bleiben. Jede Engine hat ein System dafür, und in diesem System landen letztlich die Strings.

2. Extraktion, die die Engine übernimmt. Unity sammelt Ihre Texte in String Table Collections. Das Localization Dashboard von Unreal sammelt sie in einem Target und exportiert sie. Godot liest eine Tabellenkalkulation oder einen gettext-Katalog. Das Ergebnis dieses Schritts ist die Datei, die Sie übersetzen werden.

3. Übersetzung, worum es in diesem Artikel geht. Eine Datei rein, eine Datei raus, im gleichen Format.

4. Re-Import und Testing. Die Datei geht dorthin zurück, wo sie herkam, das Spiel wird neu gebaut und jemand liest das deutsche Hauptmenü, um zu prüfen, ob nichts überläuft.

Nur der dritte Schritt muss Ihre Engine verlassen. Alles, was von Ihnen verlangt, die Datei vor der Übersetzung umzustrukturieren, fügt eine fünfte Aufgabe hinzu, die niemand braucht.

Warum man überhaupt lokalisieren sollte

Hier geht es um Marktpotenzial, nicht um den letzten Feinschliff. Ein Spiel, das nur auf Englisch veröffentlicht wird, ist für Menschen, die Englisch lesen, auffindbar und spielbar, der Rest der Welt bleibt jedoch außen vor.

Die “Can’t Read, Won’t Buy”-Umfrage von CSA Research unter 8.709 Konsumenten aus 29 Ländern ergab, dass 40 % der Konsumenten nicht bei Websites in einer anderen Sprache kaufen und 76 % es bevorzugen, Produkte mit Informationen in ihrer eigenen Sprache zu kaufen. Diese Forschung bezieht sich auf Online-Käufe im Allgemeinen und nicht spezifisch auf Spiele, was genau der Grund ist, warum sie hier zitiert wird: Diese Präferenz ist keine Gaming-Eigenheit, sondern so, wie Menschen generell einkaufen.

Drei weitere Effekte, die besonders für ein Spiel wichtig sind, ohne dass wir hier eine konkrete Zahl nennen, da uns keine vorliegt, die es wert wäre, veröffentlicht zu werden:

• Sichtbarkeit im Store. Eine Store-Seite in einer Sprache ist nur in einer Sprache durchsuchbar. Titel, Beschreibungen und Tags sind drei Bildschirme voller Text neben vierzig Stunden Inhalt.
• Rezensionen und Rückerstattungen. Ein Spieler, der kein Tutorial lesen kann, schreibt eine Rezension über das Tutorial.
• Reichweite pro Arbeitseinheit. Ihre Systeme, Art und Audio sind bereits fertig. Text ist das günstigste Element in Ihrem Projekt, das man vervielfältigen kann.

Wenn Ihr Spiel ein paar hundert Strings hat, ist das in jedem Fall ein Wochenende sorgfältiger Arbeit. Ab ein paar tausend Strings macht der Unterschied zwischen einem Workflow und einer bloßen Gewohnheit den gesamten Projekterfolg aus.

Einordnung gegenüber einem Translation Management System

Große Studios steuern ihre Lokalisierung über ein TMS: memoQ, Phrase, Crowdin, Lokalise und deren Konkurrenten. Das sind Koordinationsplattformen. Sie verwalten die Strings, das Translation Memory, die Reviewer-Accounts, die Workflow-Status und die Integrationen. Für ein Team von zwanzig Personen inklusive externer Dienstleister ist diese Koordination das eigentliche Produkt.

Wenn Sie ein Team von eins bis fünfzehn Personen sind, ist das normalerweise nicht Ihr Problem. Sie benötigen keine Accounts, Status-Verwaltung oder Vendor-Management. Sie müssen die exportierten Strings dieses Builds gut übersetzt haben, wobei Ihr erfundenes Vokabular erhalten bleibt, und zwar vor dem Milestone. Das ist eine Aufgabe, keine Plattform.

Um es ehrlich zu sagen: Ein TMS ist der Ort, an dem ein großes Team Menschen organisiert, und AI Glot ist der Ort, an dem eine Datei übersetzt wird. Viele Teams behalten den Export ihrer Engine als einzige Quelle der Wahrheit (Single Source of Truth), lassen ihn hier übersetzen und committen das Ergebnis, ohne überhaupt ein drittes System dazwischen zu schalten.

Was Ihre Engine exportiert und was wir lesen

AI Glot liest zwölf Formate: CSV, Excel, JSON und ARB, YAML, XLIFF, PO, Android XML, iOS .strings, Java .properties, .NET RESX, SRT-Untertitel und ZIP-Archive dieser Formate. Die zwei Formate, die Game-Engines tatsächlich verwenden, PO bei Unreal sowie XLIFF und CSV bei Unity, werden nativ unterstützt. Genau das ist der Kern dieses Abschnitts: Es gibt keinen Prozess aus Export, Konvertierung, Übersetzung und Rückkonvertierung.

Unity

Das Localization-Package exportiert String Table Collections auf drei Arten, und jede davon funktioniert hier.

XLIFF, in den Versionen 1.2 und 2.0, ist genau dafür gemacht. Die Unity-Dokumentation beschreibt den Export von String Table Collections in eine oder mehrere XLIFF-Dateien, deren Bearbeitung in einem externen Tool und den anschließenden Import der aktualisierten Übersetzungen. Genau dieser Roundtrip ist das Ziel. Senden Sie die Datei an den XLIFF-Übersetzer, und sie kommt mit den gleichen Einheiten in der gleichen Reihenfolge zurück.

CSV ist das andere Exportformat und ist leichter zu prüfen, wenn man einen schnellen Blick darauf werfen möchte. Die CSV von Unity enthält eine Key-Spalte mit dem von Ihnen zugewiesenen Schlüssel, eine Id-Spalte mit der von Unity zugewiesenen ID und eine Spalte pro Locale in der String Table. Die Variante “CSV mit Kommentaren” fügt pro Locale eine Kommentarspalte hinzu, die als Kontext für den Übersetzer dient und selbst nicht übersetzt werden darf. Diese Unterscheidung ist ein einziger Satz in Ihrer Anweisung, und genau deshalb gibt es die Seite für den CSV-Übersetzer. Es gibt einen vollständigen Durchgang durch beide Unity-Exporte mit der exakten Anweisung, die für jeden zu schreiben ist.

Google Sheets ist die dritte Option: Das Package synchronisiert eine String Table Collection mit einem Tabellenblatt. Exportieren Sie dieses Blatt als CSV oder XLSX, und Sie befinden sich wieder im ersten Fall.

Unreal Engine

Das Localization Dashboard von Unreal ist eine PO-Pipeline. Die eigene Dokumentation von Epic empfiehlt auf der Seite für Lokalisierungstools die Kombination “mit einem externen Übersetzungstool (wie Poedit, OneSky oder XLOC)” für die eigentliche Übersetzungsarbeit anstelle des integrierten Editors. AI Glot ist dieses externe Tool, mit dem Unterschied, dass die Datei keinen Menschen benötigt, der davor sitzt.

Ein PO-Eintrag besteht aus drei Teilen, die für Sie wichtig sind. Die Kontextzeile enthält die Unreal-Identität für diesen Eintrag, die aus dem Namespace und dem Schlüssel besteht. Die Quelle ist der englische Text. Der Übersetzungsslot ist leer, bis ihn jemand füllt. Senden Sie die Datei an den PO-Übersetzer, und nur dieser dritte Teil ändert sich.

Aus diesem Grund werden msgctxt und msgid als Struktur und nicht als Text behandelt. Ändern Sie eines davon, und Unreal kann den Eintrag entweder nicht zuordnen oder betrachtet die Übersetzung als veraltet.

Godot und mobile Builds

Godot unterstützt beide Wege. In der Dokumentation heißt es, dass es einen Importer für CSV-Dateien gibt und dass es auch das Laden von Übersetzungen im gettext-Format .po unterstützt. Beides sind Formate, die wir bereits lesen können.

Wenn Sie für Mobiltelefone entwickeln, sind die Strings für den Store und die Plattform Android strings.xml und iOS .strings. Für beide gibt es eigene kostenlose Tools: Android XML und iOS .strings. Untertitel für Cutscenes und Trailer sind im SRT-Format, was dem gleichen Workflow entspricht wie das Übersetzen von YouTube-Untertiteln.

Wir behaupten nicht, Unity, Unreal, Godot oder eine Lokalisierungsplattform zu ersetzen. Wir verarbeiten das, was diese exportieren.

Eine Spalte pro Sprache oder eine Datei pro Sprache

Dies ist der wichtigste Punkt, den Sie verstehen müssen, bevor Sie eine Anweisung schreiben, da er darüber entscheidet, was Sie überhaupt anfordern können.

So ist “Übersetze mein Spiel ins Französische, Deutsche, Spanische und Japanische” ein einziger Auftrag, wenn Sie ein Unity-CSV mit vier Sprachspalten haben, aber vier separate Aufträge, wenn Sie vier Unreal-PO-Dateien haben. Ein Format, das nur eine Sprache unterstützt, kann nicht zwei Sprachen enthalten. Dies schlägt bereits in der Planungsphase fehl und nicht stillschweigend, was genau die richtige Stelle für einen Fehler ist.

Einen Ordner mit Sprachdateien als ein Archiv senden

Ein Game-Repository enthält nicht nur eine einzige Lokalisierungsdatei. Es enthält pro Kultur ein Verzeichnis, in dem jeweils die Datei mit demselben Namen liegt. Dieser gesamte Baum wird als eine einzige ZIP-Datei hochgeladen, wofür der ZIP-Übersetzer gedacht ist.

Die Limits sollten Ihnen bekannt sein, bevor Sie das Archiv erstellen: bis zu 200 Dateien, 20 MB für das Archiv und 4 MB pro Datei darin. Größere Einzeldateien sind in Ordnung, da hier die Grenzen deutlich höher liegen: 60 MB für CSV, 50 MB für XLSX, 12 MB für XLIFF, Android XML und RESX, 8 MB für JSON sowie 4 MB für PO, YAML, .properties, .strings und SRT.

Jede Datei im Archiv muss das gleiche Format haben und dieselbe Struktur aufweisen. “Dieselbe Struktur” bedeutet je nach Format etwas anderes:

• CSV: identische Spalten in der gleichen Reihenfolge.
• Android XML, iOS .strings, Java .properties, RESX: ein identischer Satz an Keys. Ein pro Kultur erstellter Ordnersatz erfüllt dies automatisch, da er aus einer einzigen Quelle generiert wird.
• XLIFF: dieselbe Version und dieselbe Einheitstruktur. Die Dateien können jeweils unterschiedliche Sprachpaare deklarieren, weshalb ein gemischter Export mehrerer Ziele weiterhin ein einziges Archiv bleibt.
• PO: beliebige PO-Dateien, da die Struktur eines Katalogs seinem Format entspricht.

Ein Archiv, das die Strukturprüfung nicht besteht, wird mit Angabe der Diskrepanz abgelehnt, anstatt nur halbfertig verarbeitet zu werden.

So läuft eine Übersetzung jetzt tatsächlich ab

Es gibt keinen Bildschirm zur Spaltenzuordnung und keinen Konfigurationsschritt. Seit August 2026 gibt es keine festen Modi mehr, aus denen man wählen kann.

1. Laden Sie die Datei hoch, die Ihre Engine exportiert hat.
2. Sagen Sie in einfachem Englisch, was Sie benötigen. Ein Satz oder fünf.
3. Prüfen Sie den Plan. Er zeigt die Sprachen, den erkannten Umfang, die Wortzahl und die Kosten.
4. Korrigieren Sie ihn, falls er falsch ist. Das ist kostenlos und beliebig oft wiederholbar.
5. Genehmigen Sie ihn. Dies ist der Schritt, bei dem Credits verbraucht werden.
6. Laden Sie eine Datei herunter, im Format, in dem Sie sie gesendet haben.

Die Anweisung ist Freitext und die Engine kompiliert diesen in verifizierten Code. Deshalb funktionieren hier Umfang-Sätze, die kein maschineller Übersetzer ausdrücken kann: “nur die Einträge, deren Übersetzung noch leer ist”, “nur die Zeilen, in denen die deutsche Spalte noch den englischen Text enthält”, “übersetze den Dialog und die Item-Namen, lass die Entwicklerkommentare unberührt”.

Alles bis Schritt fünf ist kostenlos. Einen Plan, der Ihre Datei falsch gelesen hat, können Sie kostenlos korrigieren, es gibt also nie einen Grund zu raten.

Text, der passen muss

Ein Button, der auf Englisch passt, läuft im Deutschen über. Übersetzter Text ist typischerweise 15 bis 30% länger. Eine UI, die auf die englische Breite ausgelegt ist, ist eine UI, die auf den kürzestmöglichen Fall ausgelegt ist.

Der falsche Ansatz ist es, erst zu übersetzen und danach zu kürzen, was zu Abkürzungen führt, die niemand wählen würde. Der richtige Weg ist, die Einschränkung vorab zu nennen, damit die Zeile so geschrieben wird, dass sie passt:

Keep every UI label under 28 characters, including spaces. If the natural
translation is longer, choose a shorter phrasing rather than abbreviating.

Dies gehört in die Anweisungen auf String-Ebene, die bei der Genehmigung übermittelt werden, da eine Zeichenobergrenze etwas beschreibt, das innerhalb eines einzelnen Strings sichtbar ist. Fordern Sie dies einmal pro Datei an, und es wird angewendet, während jedes Label geschrieben wird.

Zwei Dinge ersetzt dies nicht. Testen Sie die längsten Strings im Build, da eine Zeichenobergrenze keine Messung von Pixeln in Ihrer Schriftart ist. Und bleiben Sie bei der Obergrenze ehrlich: 28 Zeichen für einen Button, nicht 28 Zeichen für eine Questbeschreibung, sonst erhalten Sie Questbeschreibungen, die wie Telegramme klingen.

Die zwei Anweisungen, die oft verwechselt werden

Dies ist der einzige Punkt im gesamten Workflow, der lautlos fehlschlägt, daher sind diese dreißig Sekunden investiert.

Die Plan-Anweisung entscheidet, was übersetzt wird. Sie wird einmalig anhand der Struktur der gesamten Datei gelesen; hier gehören die Zielsprache und der Umfang hinein. “Übersetze jeden Eintrag, dessen Übersetzungsfeld noch leer ist, ins Deutsche.”

Die Anweisungen auf String-Ebene werden angewendet, während jeder String geschrieben wird. Zu diesem Zeitpunkt betrachtet die Engine nur einen einzigen String. Daher können diese Anweisungen nur beschreiben, was darin sichtbar ist: eine Zeichenobergrenze, ein Register, ein Platzhalter wie {count}, der exakt so bleiben soll, oder ein Name, der nicht übersetzt werden darf.

Setzen Sie eine Zeichenobergrenze in den Plan, bewirkt dies nichts Nützliches. Schreiben Sie “überspringe die erste Spalte” oder “übersetze nur die zweite Hälfte der Datei” in das Feld für String-Ebene, bewirkt dies gar nichts, da zu diesem Zeitpunkt keine Datei im Blickfeld ist. Es gibt keine Fehlermeldungen. Sie erhalten einfach ein Ergebnis, das Ihre Anweisungen ignoriert hat.

Namen, Items und Zaubersprüche, die konsistent bleiben müssen

Bei der Lore unterscheidet sich die Spielübersetzung von allem anderen. Ein Produktkatalog hat hundert Begriffe, die fix bleiben müssen. Ein Spiel hat Tausende, sie sind erfunden und kehren in Tausenden von Zeilen und in jedem Update, das Sie in den nächsten drei Jahren veröffentlichen, wieder.

Hinterlegen Sie diese einmalig in einem Workspace Glossar: Charakternamen, Ortsnamen, Gegenstände und Zauber, die Hausübersetzung einer wiederkehrenden Phrase sowie Namen, die überhaupt nicht übersetzt werden dürfen. Ein Glossar gehört zu einem Sprachpaar und wird beim Erstellen eines Plans als Snapshot gespeichert. So wird ein bereits laufender Batch nicht nachträglich geändert und die nächste Datei erhält die aktuellen Begriffe.

Es lohnt sich, die Limits Ihres Plans mit Ihrer Terminliste abzugleichen: Ein Glossar mit 50 Begriffen im Free-Plan, drei mit jeweils 150 im Starter-Plan, unbegrenzt viele Glossare mit jeweils 500 Begriffen im Pro-Plan.

Und Sie müssen diese Liste nicht selbst tippen. Das Glossar ist über den MCP-Server erreichbar, inklusive Tools zum Auflisten, Lesen sowie Hinzufügen, Ändern oder Ersetzen von Begriffen. Ein Agent, der Ihr Projekt bereits geöffnet hat, kann also den mühsamen Teil übernehmen: Er liest Ihre String Tables oder Dialogdateien, filtert Eigennamen und wiederkehrende Kunstwörter heraus, schlägt Ihnen diese als Liste vor und schreibt die von Ihnen genehmigten Begriffe in den Workspace, noch bevor eine Übersetzung startet.

Das ist wertvoller, als es klingt. Ein Glossar, das niemand ausfüllt, schützt gar nichts. Und ein solches manuell für ein Spiel mit tausend erfundenen Begriffen zu erstellen, ist genau die Aufgabe, die ewig aufgeschoben wird. Lassen Sie Ihren Agenten einen Entwurf erstellen und bearbeiten Sie dessen Liste, anstatt eine komplett neu zu schreiben.

Dies ist auch der technische Grund, warum allgemeine maschinelle Übersetzer bei Spielen scheitern. Ihr Glossar ersetzt einen Begriff einfach überall dort, wo er passt, wodurch der umgebende Satz nie neu bewertet wird. Ein erfundenes Substantiv mit einem bestimmten Genus landet so mitten in einem französischen Satz, ohne dass die grammatikalische Übereinstimmung gewahrt bleibt. Hier wird das Glossar als Bedeutung einbezogen, während die Zeile geschrieben wird, sodass der Begriff korrekt in den Satz inflektiert wird. Derselbe Unterschied gilt für den Einsatz eines Chat-Assistenten für diese Aufgabe: Bei zehn Strings funktioniert es gut, aber bei String 18.000 kann er eine einzige Regel nicht mehr zuverlässig einhalten.

Lassen Sie einen Agenten Ihren Game-Localization-Loop steuern

Das ist der Teil, mit dem die meisten Studios noch nicht nachgezogen haben. Es gibt eine REST API, ein Command-Line-Tool und einen MCP-Server, sodass ein Coding-Agent den gesamten Loop ausführen kann, ohne dass ein Mensch einen Browser öffnen muss.

Installieren Sie es und melden Sie sich einmal an:

npm install --global @ai-glot/cli
aiglot auth login

Das öffnet einen Browser, um die Maschine zu autorisieren. Auf einem Build-Server ohne Browser bietet aiglot auth login --device den Device-Code-Flow, und aiglot auth login --key <key> funktioniert in der CI.

Der Prompt für Ihren Agenten

Fügen Sie dies ein und passen Sie die Pfade sowie die Sprachliste an. Dieser Text ist so geschrieben, dass er einem Agenten übergeben und nicht selbst ausgeführt wird.

My Unreal project is at ~/dev/starfall. The Localization Dashboard exported
PO files to Content/Localization/Game/<culture>/Game.po, and their msgstr
lines are still empty.

Translate the French, German, Spanish and Japanese files with the aiglot CLI.
Read `aiglot batches create --help` and `aiglot batches approve --help` first
so you use the real flags, and run `aiglot languages` to confirm each language
tag before you start.

A PO file holds one target language, so create ONE batch per culture, four in
total. The source language is English: say so explicitly in every instruction
rather than letting it be inferred.

The plan instruction should translate only the entries whose msgstr is still
empty, and leave msgctxt, msgid and every placeholder or rich-text tag exactly
as written.

At approval, pass this as the string-level instruction: "Keep UI labels under
28 characters. Keep placeholders exactly as written. Do not translate any name
that appears in the glossary."

Show me all four plans, the total word count and the cost BEFORE you approve
anything, then wait for me to confirm.

After I confirm, approve with the lite quality tier, poll until each batch
reaches a terminal status, and download each result next to the original as
Game.translated.po. Do not overwrite the source files. Tell me if any batch
failed.

Vier Dinge in diesem Prompt leisten die eigentliche Arbeit, und das sind die Teile, die Sie in Ihren eigenen Prompt kopieren sollten.

Er weist den Agenten an, zuerst die Hilfe zu lesen. Ein Agent, der Flag-Namen rät, scheitert beim ersten Aufruf und erfindet dann einen plausiblen Grund dafür. Das Lesen der echten Hilfe, oder aiglot help --json für den gesamten Befehlsbaum auf einmal, verhindert dies.

Er legt explizit fest: ein Batch pro Kultur. Ein Agent, der davon ausgeht, dass ein einziger Job vier Zielsprachen abdecken kann, wird eine Anweisung schreiben, die eine PO-Datei nicht verarbeiten kann. Sie würden dann einen kompletten Plan-Zyklus opfern, nur um das herauszufinden.

Er nennt die Quellsprache. Ohne diese Angabe wird die Quelle aus dem Inhalt abgeleitet. Diese Ableitung ist genau dort am unzuverlässigsten, wo es am meisten kostet: bei kurzen UI-Labels, Dateien mit bereits vorhandenen übersetzten Zeilen oder Texten voller erfundener Namen.

Er setzt einen Stopp vor den Kosten. aiglot batches approve ist der einzige Befehl, der Credits kostet. Alles davor ist kostenlos und wiederholbar, sodass es nichts kostet, zuerst vier Pläne einzufordern. Diese Eigenschaft macht einen unbeaufsichtigten Agenten-Loop vernünftig statt beängstigend: Ein Agent, der Sie missversteht, verbrennt Pläne, kein Geld.

Was der Agent tatsächlich ausführt

for pair in fr:French de:German es:Spanish ja:Japanese; do
  code=${pair%%:*}
  lang=${pair#*:}
  po=~/dev/starfall/Content/Localization/Game/${code}/Game.po

  # 1. Create the batch. Free. Returns the file and its plan.
  id=$(aiglot batches create "$po" \
        --instruction "The source language is English. Translate into ${lang} only the entries whose msgstr is still empty. Leave msgctxt and msgid exactly as they are, and keep every placeholder and rich-text tag untouched." \
        --json | jq -r '.data.id')

  # 2. Read the plan, still free.
  aiglot batches get "$id" --json | jq '.data.plan'

  # 3. Approve. The only step that spends credits.
  aiglot batches approve "$id" --quality lite \
    --instructions "Keep UI labels under 28 characters. Keep placeholders exactly as written."

  # 4. Wait for a TERMINAL status, not for a specific one.
  until status=$(aiglot batches get "$id" --json | jq -r '.data.status'); \
    [ "$status" = "completed" ] || [ "$status" = "failed" ] || [ "$status" = "cancelled" ]; do
    sleep 5
  done

  [ "$status" = "completed" ] && \
    aiglot batches download "$id" --output "${po%.po}.translated.po"
done

Ein Detail ist es wert, übernommen zu werden, selbst wenn Sie nie ein Spiel übersetzen. Der Loop wartet auf jeden Terminal-Status, anstatt nur auf completed zu prüfen. Ein Skript, das nur auf den erhofften Status wartet, wartet bei einem Fehler ewig, da ein Vergleich mit einem Wert, der nie eintrifft, kein Fehler ist. Er ist einfach immer falsch.

Wenn Ihr Agent Tools einer Shell vorzieht, bildet aiglot mcp die Brücke zum MCP-Server. Die CLI ist der bessere Startpunkt: Sie funktioniert in einem Skript, sie funktioniert in der CI und Sie können genau lesen, was ausgeführt wurde.

Die andere Hälfte: ein Agent, der nur die Dateien vorbereitet

Vollautomatisierung ist nicht die einzige nützliche Form und für den ersten Durchgang oft nicht die richtige.

Ein Agent ist genauso wertvoll, wenn er nur den langweiligen Teil erledigt und dann stoppt. Bitten Sie ihn, das Repository zu durchsuchen, jede Lokalisierungsdatei zu finden, zu melden, welche Kulturen existieren und welche Einträge noch unübersetzt sind, und eine einzige ZIP-Datei mit einer Datei pro Kultur zu erstellen. Dann laden Sie dieses Archiv selbst hoch, prüfen den Plan, geben ihn frei und lassen den Agenten die Ergebnisse anschließend wieder in die richtigen Pfade zurückschreiben. Diese Aufteilung lässt die zwei wichtigen Entscheidungen beim Menschen: für welches Sprachset Sie bezahlen und ob der Plan korrekt ist. Die Maschine übernimmt das Dateihandling, also den Teil, der wirklich mühsam und fehleranfällig ist. Die Seite für Game-Localization-Lösungen zeigt denselben Prozess im Browser, falls Sie ihn lieber sehen möchten, bevor Sie ihn skripten.

Wo der Mensch weiterhin hingehört

Wir wollen Ihnen nicht vorspielen, dass KI-Übersetzungen einen Spieleübersetzer ersetzen, denn gerade bei Spielen tun sie das nicht.

Nutzen Sie es für die Masse. UI-Strings, Gegenstands- und Ausrüstungsbeschreibungen, Tooltips, Namen von Errungenschaften, Patchnotes, die Flut an Barks und Flavour-Texten. Das ist das Volumen, das Studios dazu bringt, die Lokalisierung um ein Jahr zu verschieben, und es ist in einem ersten Durchgang unauffällig.

Setzen Sie die menschliche Überprüfung dort ein, wo sie wirklich einen Mehrwert bietet. Die erste Spielstunde, die Stimmen Ihrer Hauptcharaktere, alles Komische, alles, was sich reimt. Ein erster Durchgang plus ein Reviewer ist eine effiziente Nutzung eines Experten und eine bessere Alternative zu einer Woche, die in Dateien verbracht wird.

** Beauftragen Sie direkt einen Spezialisten** für Ihre Store-Seite und Ihren Trailer. Das sind die zwei Texte, die darüber entscheiden, ob überhaupt jemand den Rest sieht.

Der Grund, warum diese Aufteilung funktioniert, ist, dass Volumen und Wichtigkeit nicht korrelieren. Sobald man das erkennt, ergibt sich die Budgetentscheidung von selbst. Ihre Store-Seite besteht aus ein paar hundert Wörtern, die das meiste Reputationsrisiko tragen: Einen muttersprachlichen Experten dafür zu bezahlen, ist absolut gesehen günstig und offensichtlich sinnvoll. Ihre neuntausend UI- und Item-Strings in acht Sprachen machen fast das gesamte Wortvolumen aus, bergen aber kaum dasselbe Risiko. Kein Budget überlebt hier einen Preis pro Wort.

Verarbeiten Sie das Volumen also hier und legen Sie dann Ihre eigene Obergrenze fest. Einige Studios spielen die Ergebnisse direkt in den Build ein. Andere lassen die zwei wichtigsten Märkte oder nur die Quest-Texte professionell prüfen und lassen den Rest so, wie er zurückkommt. Beides ist vertretbar und keines davon ist die bloße Reparatur eines mangelhaften ersten Durchgangs.

Automatisierung sorgt dafür, dass die Zeit der Experten in die Sprache und nicht in die Dateiverwaltung fließt. Das ist das gesamte Versprechen, und es ist ehrlich.

Beginnen Sie mit der Datei, die Sie bereits haben

Exportieren Sie aus Ihrer Engine. Senden Sie diese Datei. Lesen Sie den Plan. Es entstehen keine Kosten, bis Sie zustimmen, daher besteht der Aufwand, um herauszufinden, ob dies zu Ihrem Projekt passt, lediglich aus einem Upload und zwei Minuten Zeit.

Wenn Sie eine Unity String Table, einen Ordner mit Unreal PO-Dateien oder eine Tabellenkalkulation mit Dialogen haben, die seit dem letzten Milestone warten, ist das die Grundlage. Registrieren Sie sich bei AI Glot und übersetzen Sie zuerst eine Datei, bevor Sie einen Agenten auf den Rest ansetzen.