How to make a translation patch

A translation patch is not a copy of a game. It is the translator's work — the lines, plus enough information to say which line belongs where — in a form someone else can apply to their own copy. Every market has its own name for the thing: a Korean patch, a Russian localizer, a Chinese localization. The artifact is the same everywhere, and so is the job of making one.

Two kinds of patch, and the fork decides everything

Before any text is touched, decide which of two things you are building, because almost every later decision follows from it.

A runtime overlay translates while the game runs. Something loads alongside the game — a plugin inside the engine, a text hook reading the game's memory, or an on-screen capture that reads pixels — catches each line as it is about to be drawn, and swaps in a translation. Nothing about the game changes on disk. XUnity.AutoTranslator is the well-known example for Unity, and MTool works this way for RPG Maker.

A patched build puts the translation into the game's own files. The text is read out of the data the engine actually loads, translated, written back, and the result is a game folder that starts and plays on its own with nothing running beside it. This is what RuneTranslate produces, and what Translator++ produces on the engines it parses.

The honest trade, stated flatly:

• An overlay needs no per-game work — it either hooks the engine or it does not — but nothing is saved. Every line is re-translated on every playthrough, on every machine, and every player has to install and configure the overlay themselves.
• An overlay only reaches text the moment it is drawn. Text baked into artwork, text that never passes through the component being hooked, and text drawn by a custom renderer stay untranslated.
• A patched build costs you an export step and a test pass, and it has to be redone when the game updates. What you get back is permanent: the file holds the translation, so the game simply is translated, offline, for anyone who applies your work.
• A patched build gives you an editable record. You can fix one bad line six months later without re-translating anything else — an overlay has nothing to fix, only a cache to clear.

If you are translating for yourself, once, on an engine you cannot parse, an overlay is a reasonable answer and there is no shame in it. If you intend to hand your work to other people, you want a patched build — because a patch is only shareable if it exists as a file.

What you need before you start

• A copy of the game you own, installed and playable. Play a few minutes of it first — you cannot judge whether a translation reads correctly if you have never seen the context.
• Knowledge of which engine it uses. This determines everything about how the text comes out and goes back in.
• A target language you actually read. Machine translation gets you a draft; it does not get you a patch.
• Disk space for a second copy of the game. A patched build is a separate folder — your original is never modified.

Identifying the engine is usually a matter of looking at the game folder. A www/data or data folder of JSON files is RPG Maker MV or MZ; a <Game>_Data folder is Unity; game/*.rpy or .rpa archives are Ren'Py; .xp3 archives are Kirikiri. The full list of what can be parsed, with the tells for each, is on the engines page — RuneTranslate covers 17 engines and formats, and detection is automatic once you point it at the folder.

The workflow

Regardless of engine, making a patch is the same five steps in the same order. The temptation is to skip step three. Do not.

1. Extract — read every translatable string out of the game's own files into a list you can work in.
2. Translate — run the list through a machine provider to get a complete first draft.
3. Review — go through the lines a machine reliably gets wrong: names, honorifics, terminology, anything with a placeholder in it.
4. Export — write the translations back into the game's format and produce a playable build.
5. Test — launch that build and actually play it.

Extract

Extraction is where engine knowledge earns its keep. Dialogue rarely sits in a plain text file: RPG Maker stores it in event command codes, Unity in TextAsset payloads and MonoBehaviour fields inside binary asset files, Kirikiri in scripts inside an encrypted archive, Unreal in .locres tables inside a .pak. A good extractor also knows what not to hand you — a scene name, a variable key, a comparison operand and an asset path all look like strings and all break the game if translated. Text painted into artwork is a separate problem with a separate tool; see image translation.

Translate

Get a full machine draft before you hand-edit anything, so you are correcting text rather than staring at a blank column. RuneTranslate ships 9 providers — Google, free DeepL and DeepL Classic/Next-gen need no API key at all; DeepL's API, OpenAI, Anthropic Claude, DeepSeek, any OpenAI-compatible endpoint and a local model through Ollama or LM Studio are the rest. The free tier unlocks every one of them and every engine; what it limits is throughput and holding more than one project at a time. Which provider suits which kind of game is covered in the provider comparison.

Review

This is the step that makes a patch worth applying. Machine output is fluent and confidently wrong in predictable places, so work through those places deliberately rather than reading everything top to bottom:

• Character names. A machine translates them differently every time it sees them, and sometimes translates them as words. Decide the spelling once.
• Honorifics and register. Keeping -san / -chan or dropping them is a project-wide decision, not a per-line one. So is whether a character speaks formally.
• Terminology. Skills, items, places, systems, anything the game invented. A skill named three ways across the menu, the tooltip and the battle log reads as a broken game.
• Placeholders and control codes. Anything like \C[1], {player} or [name] must survive intact. A translated placeholder is a crash or a blank, not a typo.
• Lines that came back unchanged. Usually onomatopoeia, and usually a sign the provider gave up on that line.

Terminology consistency

More patches are abandoned over inconsistency than over bad prose. Players forgive a stiff sentence; they do not forgive the same character being Yuuki, Yuki and Snow in one conversation, because it stops them tracking who is talking. The fix is a glossary: a list of source terms and the exact target term each must become, applied before translation so the provider never gets the chance to improvise. Build it early, from the names you meet in the first hour, and add to it as you go — the glossary guide covers how it interacts with tag masking and why it belongs at the start rather than in a find-and-replace pass at the end.

Fonts

A Japanese game ships a Japanese font, and a Japanese font frequently has no glyphs for Cyrillic, Greek, Hangul, Thai or the accented letters of Polish, Turkish and Vietnamese. Translate into one of those and the game renders empty boxes — the translation is correct, the font simply cannot draw it. Some engines are handled for you: a Ren'Py export bundles a capable font and remaps the game's fonts onto it. Where it is not automatic, replacing the font file inside the exported build usually fixes it. Literal question marks are a different fault entirely — that is the engine's own string encoding refusing a character, not a missing glyph — and the distinction is worth knowing before you go hunting for the wrong fix. Both cases are covered in the FAQ.

Test the build

An export that produced no errors is not a tested patch. Launch it and check the things that break silently:

• The game reaches the title screen and starts a new game. A build that fails here usually failed on a line that was never text — an identifier that got translated.
• Message boxes hold their text. Translations run longer than Japanese; look for lines running past the box edge or being cut off.
• Menus, item names and tooltips — the places where a long word overflows a fixed-width button.
• A save file from the original game still loads, and a new save made in the patched build loads too.
• One scene deep in the game, not just the opening. Extraction gaps show up as untranslated stretches, not as errors.

Sharing your work

Here is the part that decides whether your patch is something you can hand out. The thing you made is the translation — the lines. The game is not yours, and packaging a translated copy of it means distributing someone else's game. The honest form of a patch is the work alone, applied by each recipient to a copy they already own.

RuneTranslate exports exactly that as an .rtpatch file. It carries the unit ids, the source lines each translation matches on, and your translations. No game files, no assets, no binaries — the file is your text and nothing else, which is why it is small enough to attach to a message and safe to hand to anyone.

The recipient's side is three steps:

1. They create a project from their own installed copy of the same game, which extracts the same lines on their machine.
2. They import your .rtpatch, which fills those lines in with your translations.
3. They export their own playable build from their own game files.

Matching is by unit id first, and falls back to matching on the source line itself when ids have drifted — a game update or a change in the extractor. That fallback is what keeps a patch usable after the game patches. The import checks that the engine and the target language agree before applying anything, so a patch made for a Unity game cannot be dropped into a Ren'Py project by accident. On the free tier, patch sharing is metered at one export and one import per rolling three-day window; everything else about making the patch is unthrottled by feature.

The same file is how a team works together — one person translates the story, another the menus, and the patches merge into one project — and it is how you keep your own work when a game updates: re-extract from the new version, import your old patch, and only the lines that actually changed need attention.

Whether a game itself may be redistributed is the rights holder's call, not yours and not ours. Share the patch, tell people which version of the game it was made against, and let them bring their own copy.

Per-engine specifics

Everything above is the shape of the job. What differs per engine is where the text lives, what the export produces and what stays out of reach — and that is worth reading before you start rather than after an export surprises you: Unity, RPG Maker, Ren'Py, or the full engine list for the other fourteen.

RuneTranslate runs on Windows 10 and 11, and on Linux and the Steam Deck under Wine or Proton. A free Patreon sign-in is required on first launch; the free tier opens every engine and every provider. If you are weighing it against the overlays and toolkits people usually reach for first, the comparisons lay out what each approach actually gives you.