The most common complaint I got from users of my manga translation tool was not about translation quality on any single page. It was about page 190.
Someone would upload a whole volume, the first chapter would read fine, and then halfway through a side character would quietly change names. "Shiori" became "Siori". A guild called "the Black Hand" turned into "the Dark Hand". The honorific "-senpai" was kept on one page and dropped on the next. Each page in isolation was fine. The volume as a whole was not.
This post is about why that happens, why it is harder to fix than it sounds, and what I ended up shipping in AI Manga Translator to deal with it: a per-upload glossary with CSV import and export.
https://ai-manga-translator.com
Why names drift in the first place
A manga page goes through a pipeline: detect speech bubbles, work out reading order, OCR the Japanese, translate, inpaint the original text out, typeset the translation back in. The translation step is where names get decided.
The problem is that a name written in kanji or katakana often has several defensible romanizations, and a made-up term has several defensible translations. An LLM picks one. Ask it again with a slightly different context, and it may pick another. Over 200 pages you accumulate hundreds of these small decisions, and some fraction of them land differently.
Three things make it worse for manga specifically:
- Pages are translated in batches, not as one giant prompt. A 1,000-page archive does not fit in a single context window at usable cost, so the model sees chunks. Each chunk can drift from the last.
- Japanese drops the subject constantly. A line that is just a verb gets its subject inferred from context. If the model misreads who is speaking, it can also misattribute a name.
- Reader expectations are strict. Prose readers might tolerate a one-off spelling variation. Manga readers follow series for years and have strong opinions about whether it is "Zoro" or "Zolo".
What I tried first
Carrying context forward. I pass a summary of recently seen names and terms from earlier chunks into later chunks. This helps a lot and is the main reason the tool already kept names stable for most volumes. But "most" is not "all", and it is a soft signal: the model is told what it used before, not what it must use.
Bigger chunks. Fewer boundaries means fewer chances to drift. It also means slower first results and higher cost per job, and it still does not solve the cross-volume case, where a user translates volume 3 today and volume 4 next month.
Post-processing find-and-replace. Tempting, but you cannot safely regex a name across typeset speech bubbles after the fact, and you do not know which variant the user wanted in the first place.
None of these address the real gap: the person who knows what the names should be is the user, and I was never asking them.
What shipped: a glossary per upload
The fix was boring, which is usually a good sign. Each upload can now carry a glossary: a list of fixed renderings, source term to target term, that the translation step must respect.
Design decisions, with the reasoning:
- Per upload, not auto-saved. I considered a global glossary tied to the account. Users translate different series, and a global list would silently apply "Shiori" to a completely different character in another manga. So the glossary attaches to the job. To reuse it, you export it.
- CSV import and export. Scanlation groups already keep terminology sheets in spreadsheets. Asking them to retype into a custom UI would have killed adoption. CSV means they paste what they already have, and the exported file travels to the next volume.
- Hard cap of 100 entries. Most volumes need 10 to 30. The cap keeps the prompt budget predictable and discourages people from pasting an entire dictionary and wondering why quality dropped.
- No extra page charge. Glossary entries add tokens to every translation call, so there is a real cost. I decided it should not be a line item, because the whole point is to make long-volume translation worth doing. The alternative, where a careful user pays more than a careless one, felt backwards.
- Works with the style preview. Users can translate a few pages first, see which names appear and how they were rendered, then fill the glossary before running the full archive. Fifteen minutes of setup versus hunting for the wrong page afterwards.
How it fits in the pipeline
At a high level, the glossary is injected as a constraint into the translation step for every chunk, alongside the carried-forward context. The carried-forward context says "here is what you did before"; the glossary says "here is what you must do". When they conflict, the glossary wins.
The OCR step also benefits indirectly. Knowing that a specific katakana string is a name, not a word, lets the pipeline treat it as an atomic token instead of trying to translate it, which fixes a class of errors where a name that happens to look like a common noun gets translated literally.
I will not go into prompt specifics here, but the pattern is general enough that it applies to any batched LLM translation job: separate "what you did before" (soft, advisory) from "what the user requires" (hard, authoritative), and give the user a way to author the second one in a format they already use.
What I would tell someone building something similar
- Consistency across batches is a product problem before it is a model problem. The best model still does not know which romanization your users want.
- Let users bring their own terminology in the format they already have. For my audience that was CSV. For yours it might be a JSON file or a Notion export.
- Put the glossary where the job is, not where the account is. Scope prevents a whole category of silent errors.
- Pair it with a cheap preview step so people can discover what needs to go in the glossary before paying for the full run.
If you want to see the end result, the manga translator takes CBZ, CBR, PDF and EPUB archives, with the glossary and style preview available on every upload:
https://ai-manga-translator.com/tools/manga-translator
Happy to answer questions about the batching and context-carrying approach in the comments.
Top comments (0)