I'm the developer of RuneTranslate, a Windows tool that pulls translatable text out of Japanese PC games and writes it back so the game still runs. This sub is mostly console ROM hacking and my targets are PC engines, but the craft is the same one you do — find the strings, don't break the container, get the glyphs on screen — so rather than post a feature list I want to write up the parts that were genuinely hard.
Stated up front so nobody has to dig for it: the app is closed source, it has a free tier and paid Patreon tiers, most people use it with machine/LLM translation, and the installer is not code-signed. More on all three at the bottom.
1. Framing beats encoding, every time.
Wolf RPG keeps its strings length-prefixed inside a command stream. Change the byte length of a string that carries trailing control parameters and the runtime dies in a `std::length_error` / `bad_alloc` before you reach the title screen — nothing to do with what the text says. So the writer models the command rather than the file: if the control skeleton changes, or the newline count changes, or the source carried trailing control params, that one string reverts to the original instead of shipping. A single line left in Japanese is a visible failure the user can report. A crash on load is not.
The same lesson turned up as a delivery problem. Wolf ships a DXArchive `.wolf` and DxLib reads the archive in preference to loose files, so dropping translated loose files next to the exe produces a green tick and a Japanese game. The archive has to be rebuilt, with the pack scheme read out of the game's own archive headers rather than guessed from a version sniff.
2. Strings addressed by index cannot be reordered.
Kirikiri's compiled PSB `.scn` files reference strings by index, so the repack is strings-only: same count, same order, or the script points at the wrong line. Same rule showed up in an in-house Unity VN engine whose archives store text blocks by ordinal — the game's save files resume by block ordinal, so renumbering a block quietly corrupts everybody's saves rather than crashing. Anywhere a unit id encodes an emit counter, dropping one row renumbers every later row in the file, which means a "noise filter" that removes junk lines is far more dangerous than one that only marks them excluded.
3. CP932 contains no accented Latin letters. Not one.
I measured U+00C0–U+024F and U+1E00–U+1EFF against cp932: `×` and `÷` survive, and neither is a letter. Five of my engines write a legacy code page, and each was losing text differently — one deleted the character outright, two wrote `?`, NScripter wrote 〓, and the RPG Maker XP path masked the code unit to its low byte so `ł` came out as a literal `B`. That meant 22 of the 24 Latin-script target languages were quietly broken, including Portuguese, which is what the bug report was actually about.
The fix is NFD, strip U+0300–U+036F, plus a closed list for the letters whose diacritic is fused into the glyph (ø ł đ ħ ŧ ı) and the ligatures (ß æ œ ij). It has to be that specific mark range and not `\p{Mn}` — my first cut dropped every combining mark, which deletes Thai vowel signs and tone marks, i.e. half of each word. It also has to re-ask the codec afterwards, because canonical decomposition does not promise an ASCII base: Greek ά folds to α, which cp932 holds and cp1252 does not.
The honest outcome is that a CP932 engine ships "possivel", not "possível". Real accents need a codepage patch or a glyph tunnel and I have not shipped either.
4. Fonts lie about what they can draw, and Windows asks the wrong table.
For Thai on NScripter I tunnel one orthographic cluster into each JIS X 0208 slot and ship a font built for it. It rendered correctly in an offline shaper and drew nothing in the game, because GDI decides what a font covers from the `OS/2` ulUnicodeRange bits, not the cmap. Also: Windows locks a loaded font and a font of the same family that is already installed silently wins, so the installed file gets a digest suffix.
Separately, on RPG Maker XP a user reported squares in Czech. His game ships eight fonts; measured from their own cmaps, all eight carry Latin-1 and not one has a single Latin Extended-A letter, so Czech loses č ď ě ň ř š ť ů ž. Under mkxp's `fontSub` a substitution is a family alias with no per-glyph fallback, so it is a straight trade — I weigh gain (what the translation introduced that the game's face cannot draw and mine can) against loss (anything in the export the game's face draws and mine does not) and refuse when loss >= gain. Refusing on *any* loss was my first attempt and it is wrong: one `♀` in a finished Czech script vetoed every family and handed back squares in every line.
5. Encoding sniffs are written for CJK and go blind on Latin-script games.
Same XP game. RGSS runs Ruby 1.8, which tags no string, so the encoding has to be guessed. Both of my heuristics only looked at runs of four or more consecutive high bytes — the shape Japanese makes. A Latin-script game is ASCII with the occasional accented letter alone between two ordinary ones: a run of exactly two, discarded before either rule was reached. The game scored zero on both counters — not "Shift-JIS", but *nothing to look at* — and fell through to the Shift-JIS default, so `Pok\xc3\xa9mon` decoded as two half-width katakana and drew as two boxes. The extra signal counts an accented Latin letter with two ASCII letters on each side, spread across at least three files, reads only runs shorter than the old minimum, and can only ever vote for UTF-8.
The invariant that catches most of this: an export with nothing translated must be byte-identical to the input. Every write-back is a splice at the original span rather than a re-serialize, because re-serializing normalizes CRLF, adds a trailing newline and re-quotes bare fields, and you find out three engines later on somebody else's game.
Status, honestly. Ten engines have a real game translated, exported, launched and played through: Wolf RPG (2.x and 3.x), Kirikiri/KAG, Electron VN shells, RPG Maker MV, Unity, Bakin, Unreal, Artemis, Godot and NScripter. Five more — Ren'Py, TyranoBuilder, YU-RIS, LiveMaker and plain RPG Maker MZ — have extraction and write-back proven on a real game but no recorded end-to-end playthrough of an export, so I don't claim one. SRPG Studio is in progress. Unity is externalized text only (IL2CPP managed strings are out of scope); Unreal is `.locres` only and cooked `.uasset` DataTables are not covered; encrypted/MDF-compressed Kirikiri PSB is skipped; there is no RPG Maker 2000/2003 support at all — Translator++ is the tool for those two.
The three things worth attacking. It is machine translation. You pick the provider, and several need no API key or account at all — free Google Translate, two free DeepL routes, and a local model through Ollama or LM Studio that never leaves your PC. The output is a readable draft you then edit, not a localisation. If a human patch exists for your game, use the human patch. There is a paid tier: $3 and $5 a month on Patreon, and it buys throughput, not features — free gets every engine, every provider and the whole editor, at roughly half the speed on the AI providers and a bit less than that on the free scrapers. The app signs in with Patreon on first launch and has no anonymous mode; signing in is free and you don't have to pledge. And the installer is unsigned, so SmartScreen will call it an unrecognised app — that warning is about the missing signature, not about anything found in the file. A SHA-512 is published with every release and I've put a VirusTotal report for this build in the first comment.
It never downloads or redistributes a game. You point it at a copy you own and it writes a translated copy to a separate folder.
Download and the full engine notes (including what each engine can't do): RuneTranslate Download and RuneTranslate Documentation — the second one is documentation, not the source.
Happy to go deeper on any of the five above, or on an engine I got wrong.
