ai newsFr., 30. Okt.
EilmeldungMistral Large 4 Weights Are Out – What It Means for Building LLM Infrastructures

Keeping character names consistent across 1,000 manga pages: why I added a glossary to my AI translator

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"

dev.toFreitag 10:50 · 30.10.3 Min. Lesezeit
Bild: dev.to

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.

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:

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.

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.

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.

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.

Quelle: dev.to (dev.to). Original öffnen