translate-book shows the governance boundary for agentic translation pipelines
translate-book is useful when its chunks, glossary, run state, manifest validation, and output formats are treated as governance controls rather than convenience features.
translate-book is interesting because it exposes the real governance problem in agentic translation. The question is not whether an AI agent can translate a chapter. The question is whether a long translation run can be resumed, audited, selectively repaired, and exported without hiding errors inside a chat transcript.
The project is a Claude Code skill published as deusyu/translate-book. It translates PDF, DOCX, and EPUB inputs into target languages by converting source files into Markdown chunks, dispatching parallel subagents, validating chunk outputs against a manifest, and building HTML, DOCX, EPUB, and PDF files. The repository uses Python, carries an MIT license, and documents Calibre, Pandoc, Claude Code CLI, and pypandoc as important dependencies.
Agentic translation needs artifacts, not just agents
Many agent workflows overemphasize orchestration and underemphasize artifacts. translate-book is stronger because the artifacts are visible: chunk files, output_chunk files, manifest.json, source_fingerprint.json, glossary.json, run_state.json, and final book outputs. These files create an audit trail.
That audit trail matters. If a source file is replaced after conversion, source fingerprinting can prevent silent reuse of stale chunks. If a chunk output is missing or blank, merge validation should fail. If a glossary term changes, run state can identify affected chunks. These are governance controls, not mere implementation details.
Parallelism creates consistency debt
Using multiple subagents improves throughput and avoids context accumulation, but it also fragments translation memory. Every fresh-context worker may make slightly different choices. The project’s glossary mechanism is therefore central: terms are extracted from sampled chunks, frequencies are counted, and a per-chunk term table is injected into the translation prompt.
This is a practical compromise. It does not deliver professional translation memory, but it gives the workflow a shared terminology layer. For many technical books, manuals, and internal documents, that may be enough if a human editor reviews the glossary before and after the run.
The risks are outside the repository too
The repository can manage chunks and outputs, but it cannot solve copyright, confidentiality, model-provider policy, or final editorial quality. Those are adoption decisions. A team should define what documents may be sent to an AI model, who approves glossary choices, how samples are reviewed, and whether generated EPUB/PDF files are considered drafts or publishable artifacts.
Source quality is another boundary. Calibre and Pandoc are powerful, but scanned PDFs, unusual footnotes, tables, math, and multi-column pages can produce noisy Markdown. A governed workflow should inspect the converted Markdown before translation, not only the final PDF after translation.
A useful adoption checklist
- Run a small baseline book first and inspect every generated artifact.
- Confirm Calibre, Pandoc, Python, and Claude Code versions in the environment.
- Review input.md and sample chunks before launching parallel translation.
- Build or edit glossary.json before expensive work begins.
- Keep the temp directory for resumability and forensic review.
- Sample final output across early, middle, and late chapters before distribution.
translate-book is best seen as a disciplined agent pipeline for translation drafts. It gives teams a better control surface than a single long prompt, but it still needs human policy around rights, privacy, terminology, and publication quality.