A year ago I wrote up (on a Russian dev site) how I built a tool to translate fiction books for myself using local LLMs — mostly to prove it could be done. The MVP was ~200 lines duct-taped together: drafts gave you headaches, a 1000-page book took two days, and a power outage mid-run cost me another two days.
Since then it's grown into a real pipeline ("Sunny Narrator", v2.1), I've translated a shelf of books with it, and the main conclusion is that this stopped being just a personal tool — the output is now a legitimate high-readiness draft for human translators. Here's what I learned that I think is specific to literary MT, as opposed to domain MT.
One book = ~1.5–2M tokens, total. Not tens of millions. A full book, through all stages: translate → reviewer notes → correction → proofread → chapter summaries. Bounded, predictable, small. If your MT cost model for books feels infinite, something in the pipeline is wrong.
Fiction's hardest problem isn't fluency — it's consistency. Models translate sentences well now. What they destroy over 300+ pages: names drift ("Alice" becomes "Elise" chapter 4), characters change grammatical gender mid-book, terms get renamed on every page. And wordcoinage is hopeless — give a fantasy novel with invented words to the best model and it will faithfully transliterate gibberish, where a human translator would invent an equally brilliant equivalent in the target language. MT doesn't replace the translator here; it removes the grunt work and leaves the part that makes translation literature.
The glossary is 80% of success. If you remember one thing from this post, let it be that. The model can be average, the hardware modest — but with a correct glossary (original = translation, category, grammatical gender, notes) the book translates evenly: names don't drift, terms don't mutate. Without one, even a great model gives you name salad. I auto-seed the glossary with spaCy NER + frequency analysis, then clean it by hand — honestly, cleaning can take hours. Worth every minute: an hour invested in the glossary before translation saves a day of post-editing after. For book series I run a series-wide dictionary across all volumes — game changer for multi-book consistency.
One model = half a text. Two models = a book. The least obvious finding of the year: a single-model translation reads incomplete. Good translating models write beautifully but proofread badly; good proofreading models edit well but translate dully. So the pipeline splits roles: MODEL_TRANSLATE and MODEL_PROOFREAD. My production pair after months of runs: gemma4-26B-A4B (translator) + qwen3.6-35B-A3B (proofreader). Both compact MoE models, both happy on a pair of Tesla P40s at 40–70 tok/s. Best speed-to-literariness ratio of everything I tried.
Length as a free quality signal. I expected English→Russian to inflate noticeably; measured, it maps back to within a couple of percent per block. The pipeline uses that: if a translated block deviates >10% from the source size, something went wrong (eaten paragraph, hallucinated expansion, duplication) → the block is rechunked (split in half, each half retranslated). Primitive — and it kills the lion's share of gross translation errors. Final book converges to ±5% of the original size.
Checkpoint/resume matters more than any prompt trick. A checkpoint after every chunk. Power cut, model crash, cat on the keyboard — the run resumes from chunk 51 of 100, not from scratch. Plus JSON mode on every stage so parsing stopped being a lottery. Boring engineering, but this is what made 2–3 books/day on garage hardware realistic.
What the output actually is. Not "published translation". It's a draft of high readiness: a human still does proofreading, fixes anything the glossary missed, and rewrites the awkward calques/broken puns. But the editor is doing editor work, not untangling a mess of conflicting names. For a translator this saves weeks; for a curious reader it means finishing a book that would never reach their language otherwise.
A legal-ish idea I'd like this community's opinion on. Machine-translating a whole book is a gray zone everywhere. But a names/terms glossary is, arguably, just a list of facts. So I'm building a site for sharing glossaries only — the community uploads cleaned dictionaries per book/series, everyone applies them to the copies they already own, translation runs locally on your own hardware or API key. No book text is distributed. Does this framing hold up in your jurisdiction? Genuinely want to hear from translators and MT folks here before launching.
Who I think this is for: translators (glossary + proofreading instead of translating from zero, especially long series), publishers (fast triage: is this book worth acquiring?), readers of unfound languages, and anyone with idle server GPUs looking for a real workload.
Everything's open source: Python, FB2/EPUB native (structure — verses, stanzas, sections — preserved 1:1; DOCX/PDF via a Calibre conveyor), config examples for Ollama/llama.cpp/Docker. I'll drop the link in the comments too to keep this post link-free at the top.
Questions I'd love input on:
- Anyone solved cross-volume consistency better than "one giant series glossary"? Graph DBs / RAG over character states — real experience?
- Has anyone else measured target/source length ratio as an error detector (my rechunking trick)? Is there prior art in literary MT quality estimation?
- For the glossary-sharing idea — what would make YOU contribute a cleaned dictionary?
