translate-book

translate-book skill の概要

translate-book でできること

translate-book skill は、PDF、DOCX、EPUB ファイル向けの書籍翻訳パイプラインです。元の書籍を Markdown のチャンクに分割し、各チャンクを並列のサブエージェントで翻訳したあと、HTML、DOCX、EPUB、PDF に再構築します。長文コンテンツの Translation 作業で translate-book が必要なら、1 回のプロンプトでは全体を扱うには不安定すぎる、あるいは寿命が短すぎる場合に特に有効です。

どんな人に向いているか

本、マニュアル、書籍級の文書を日常的に翻訳していて、再現性のある出力、チャンク単位の再開、フォーマット再生成を重視するなら、translate-book の導入価値があります。ゼロから単発の翻訳プロンプトを書くより、ガイド付きのワークフローを使いたい人に特に向いています。短い抜粋や素早い要約だけが必要なら、メリットは小さめです。

何が違うのか

translate-book skill の大きな差別化ポイントは、パイプライン設計にあります。変換、チャンク化、並列翻訳、ハッシュ検証、再構築がすべて明示的なステップとして分かれています。この構造によりコンテキストの欠落を抑え、最終組み立て前に欠けたチャンクや古いチャンクを見つけやすくなります。また、リポジトリがツールチェーンと出力成果物について明確な方針を持っているため、単なる「このファイルを翻訳して」という汎用プロンプトより、導入判断がしやすいのも特徴です。

translate-book skill の使い方

インストールと前提条件の確認

プロジェクトが示すインストール手順に従ったうえで、パイプラインが必要とする外部ツール python3、pandoc、Calibre の ebook-convert または calibre が使えることを確認してください。ebook-convert がない場合でも translate-book install 自体は成功するかもしれませんが、実際のワークフローは変換時に失敗します。まず実行環境を確認するのが安全です。

完成形の入力プロンプトから始める

この skill は、1 回のリクエストでファイルパス、対象言語、スタイル制約までまとめて伝えると最もよく動きます。たとえば、Translate /path/to/book.epub into Japanese, keep technical terms consistent, preserve chapter structure, and use a formal tone. のようなプロンプトが適しています。これなら translate-book usage が十分な文脈を持ってパラメータを選べるため、やり取りの往復を減らせます。ファイルパスを省略した場合は、skill 側で停止して確認を求めるはずです。

先に読むべきファイルを押さえる

導入判断のための確度を上げるなら、まず SKILL.md を読み、その後に README.md、実装やテストのメモを確認したい場合は AGENTS.md と CLAUDE.md も読んでください。このリポジトリでは、README を流し見るよりスクリプトのほうが重要です。scripts/convert.py、scripts/manifest.py、scripts/glossary.py、scripts/merge_and_build.py を見れば、チャンクの生成、管理、一貫性の担保、再構築の流れが分かります。translate-book が自分のワークフローに合うかを最短で見極めるには、ここを押さえるのが一番です。

チャンクを意識したワークフローで使う

これは 1 回の翻訳呼び出しだと考えないでください。意図された流れは、入力ファイル → Markdown チャンク → 翻訳済みチャンク出力 → 結合済み書籍、です。プロンプトでは、チャンク品質に影響する要素を明記しましょう。脚注、表、コードブロックを必ず残す必要があるか、固有名詞は翻訳しないか、書籍全体で用語集の一貫性が必要か、といった点です。こうした情報があると、後で食い違う局所判断が減ります。

translate-book skill FAQ

translate-book は初心者向きか

はい、ファイルパスと対象言語を指定できるなら使えます。skill が多段階のパイプラインを隠してくれる一方で、書籍レベルの制約、つまり書式の忠実さや用語の一貫性については理解しておく必要があります。初心者は、最初から大きなスキャン PDF に挑むより、短い EPUB や DOCX から始めるほうが成果が出やすいです。

どんな場合に translate-book を使うべきでないか

短い文、カジュアルなチャット翻訳、ざっくり意味が分かれば十分なケースには向きません。また、OCR 精度の低いスキャン PDF のように、著しく読み取り品質が悪い入力にも不向きです。元の変換品質が低いと、その後の翻訳品質もそこに引きずられます。入力ファイルをきれいに変換できないなら、どんなプロンプトでも構造を完全に取り戻すことはできません。

通常の翻訳プロンプトと何が違うか

普通のプロンプトは、多くの場合 1 つのコンテキストウィンドウ内で翻訳するため、途中で切れる、文脈がずれる、用語が不一致になるリスクがあります。translate-book はチャンク化、検証、再構築を前提にしているので、連続性が重要な長文に向いています。その代わり、初期設定と依存関係の確認は少し増えます。

translate-book はどの言語ペアでも使えるか

この repo は複数の対象言語を想定していますが、品質はソースの複雑さと専門用語の多さにも左右されます。最良の結果を得るには、対象言語コードを明示し、ドメイン用語について glossary の指示を与えるのが有効です。翻訳中心のプロジェクトでは、その一貫性の指示は言語選択そのものと同じくらい重要です。

translate-book skill の改善方法

ソース側の制約をより明確に伝える

品質を大きく上げる最短ルートは、translate-book に「何を変えてはいけないか」を伝えることです。保持したい章タイトル、英語のまま残す用語、好ましい音訳、表やコードブロックの書式ルール、学術向けか一般読者向けかといった読者レベルを指定してください。たとえば、Keep API names unchanged, translate prose formally, and preserve Markdown headings exactly. のように伝えます。

早い段階で用語のぶれを減らす

このパイプラインは並列のサブエージェントを使うため、事前に重要用語を定義しないと用語がぶれやすくなります。大きな書籍を回す前に、名前、製品用語、繰り返し出る技術フレーズの小さな glossary を用意してください。特に translate-book for Translation のような案件では、1 つの不統一な用語が多くのチャンクに広がってしまうので重要です。

変換とチャンク化の失敗を見逃さない

よくある失敗は、OCR の崩れ、元ファイルの書式不良、表やリストを不自然に分断するチャンク境界です。最初の出力が不自然なら、翻訳品質を疑う前に、中間のチャンクファイルと manifest を確認してください。translate-book guide として最も役立つ習慣は、まずソース側のパイプラインを直し、そのうえでクリーンなチャンクに対して再翻訳することです。

最初の出力を見て反復する

初回実行のあとに確認するのは、最終的な結合後の書籍だけでは不十分です。代表的なチャンクをいくつか見て、章の冒頭、用語集の語、見出し、そして元の書式が密だった箇所をチェックしてください。必要なら、本全体を手作業で直すより、指示を絞って再実行したほうが早いです。それが次回の translate-book skill を改善する最短ルートです。