Translation glossary 101 — lock character names and terminology

Run a 200-line Japanese visual novel through DeepL and the heroine's name comes out as Alice. The next 200 lines make it Aris. The batch after that decides on Arisu. By chapter four she has three names depending on which scene you're reading.

This is the single most common failure mode of machine translation on long narrative games — not grammar, not phrasing, but inconsistent proper nouns. The provider has no memory between batches; it re-guesses the most plausible Romanization every time it sees a name. Over a 40-hour RPG, that drift makes a readable translation feel like four different people translated it.

A translation glossary fixes this. You define the source-to-target term pairs once — アリス → Alice, 勇者 → Hero, 魔王 → Demon Lord— and every translation batch, on every provider, honors them. The provider never even sees those terms in their raw form.

What a translation glossary is

A glossary in RuneTranslate is a list of three-column rules:

• source— the source-language substring to lock (Japanese by default; any supported source language), e.g. 勇者.
• target— how you want it rendered in the output, e.g. Hero.
• targetLang— which output language the rule applies to, so one glossary can cover English + Spanish + German at once.

Add 30 of these for a typical visual novel cast and you've eliminated the entire class of proper-noun drift in one shot.

How the placeholder mask works (provider-agnostic)

The naive approach — regex-swap the target term in after the provider runs — kind of works on DeepL but breaks on LLMs, which have already rephrased the sentence around the term they translated, leaving dangling articles and odd capitalization.

RuneTranslate masks glossary terms before they reach the provider. The runner walks every batched source string and replaces each glossary source with a numeric placeholder — [[G0]], [[G1]], and so on (longest matching term first, so 魔王軍 wins over 魔王). The provider sees opaque tokens it can't mistranslate. On the way back, those placeholders become your target term, then the engine-tag mask (RPG Maker codes, KAG tags, Ren’Py interpolations) is restored on top. Result: glossary terms render identically whether you're on DeepL, an LLM, or free Google Translate.

Priority order — TM beats glossary beats provider

Knowing how a batch flows through the runner explains why glossary edits don't cost provider credits and how translation memory cooperates:

1. Translation memory (TM) short-circuit. If you've already translated this exact source string in any past project, the cached translation is served instantly — zero provider calls. The unit leaves the batch before the provider sees it.
2. Glossary mask is applied to whatever units TM didn't serve.
3. Provider call runs on the masked text. This is the only step that costs money / counts against quota.
4. Restore— glossary placeholders become your target terms, then engine tags are restored on top.
5. TM write— the final translated line is cached, so next time you see this Japanese it's a free step-1 hit.

TM is the biggest cost saver; glossary is the biggest quality saver. Together they compound: hand-edit a line once, it gets cached in TM, and the glossary keeps proper nouns consistent across cache hits and fresh batches alike.

TM + glossary interplay (the bypass guard)

One subtle edge case: say you translated 100 lines with 勇者 three months ago without a glossary, and TM cached them as Warrior / Champion / Hero at random. Now you add 勇者 → Hero to the glossary.

Naively, TM would still hand back Warrior— that's what got cached. RuneTranslate guards against this: at TM-hit time, if a glossary source appears in the unit but the cached target doesn't contain the glossary's target rendering, the cache hit is bypassed and that unit falls through to a fresh provider call. The run summary shows a "N units bypassed cache to honor glossary changes" line. So adding a new glossary entry to an old project never leaves you stuck with stale names — just re-run the affected units.

Building your glossary — what to add

For a typical project, sort by impact:

• Cast list first. Every named character — pull from a wiki, VNDB, or the game's own credits screen. This alone eliminates ~80% of drift on long games.
• Places second. Towns, dungeons, regions, kingdoms — especially kanji with more than one plausible Romanization.
• Signature attacks / skills third. Boss moves, recurring spells, special-move names — important for RPGs and combat-heavy VNs.
• World-specific terminology fourth. Made-up words for races, classes, artifacts, currency.

What not to add: common words. 剣 → sword invites false positives — it locks every compound containing 剣 (魔剣, 聖剣, 剣士) that the provider would have rendered fine on its own. Entries are literal, case-sensitive substring matches, so keep them long enough to be unique to the proper noun you're locking.

CSV import / export — sharing glossaries

Translating with collaborators? The glossary tab in Settings has Import CSV and Export CSV buttons that round-trip your entries through an RFC-4180 file with the header source,target,targetLang and one term per row — e.g. 勇者,Hero,en and 勇者,Héroe,es. The header row is required; fields containing commas or quotes are wrapped in double quotes (embedded quotes doubled), and import reads UTF-8 with an optional BOM (Excel's default). Empty rows and rows with an unsupported targetLang are skipped with a per-row reason.

Import offers a Merge mode (add the CSV rows on top, dedupe by source + language, CSV wins on conflict) or Replace mode (wipe existing and use only the CSV). Merge is the right default for collaborators sharing a partial glossary; Replace is right for restoring a backup.

Current limitations

• Literal substring matches only. No regex, no wildcards — to lock both 勇者よ and 勇者だ, add two entries.
• One target language per entry. A row is tied to one output language, so "勇者 → Hero (en) + Héroe (es) + Held (de)" is three rows. The CSV format supports this naturally.
• Paid tiers only (Supporter and up). Free tier shows the glossary card, but entries don't affect translation runs; the discovery dialog points at Patreon.

Wrapping up

Of every quality lever in machine translation, the glossary has the highest ratio of effort to impact — ten minutes building it saves hours of hand-fixing inconsistent names downstream. Start with the cast list, ship a first pass, and add terms as you read through the result and notice drift.

Pair it with a provider that handles tone well (Anthropic Claude is my default for VNs) and the AI refiner, and your output is already past "readable machine translation" and into "could ship as a fan translation with light hand-editing."

Download RuneTranslate to try the glossary on a real project. It's a Supporter ($3/mo) feature; the free tier stays fully unlocked for engines and providers.