mainブランチとの差分から翻訳済みの日本語ドキュメント(.ja.md)を特定し、不自然な日本語表現を修正する。
ワークフロー
PHASE 1: 対象ファイルの特定
- •
git diff --name-only mainで変更のある.ja.mdファイルを特定する - •対応する英語版ドキュメント（
.en.mdまたは拡張子なし.md）を読み込む - •日本語版と英語版を比較して翻訳品質を評価する
PHASE 2: 不自然な日本語表現の検出と修正
以下のチェックリストに基づいて各ファイルをレビューし、問題を修正する。
見出し・セクションタイトル
- •「〜する人にとって」「〜する人のための」→ 「〜向け」（例：「読む人にとって」→「閲覧者向け」）
- •英語の直訳的な体言止めを自然な日本語の見出しに変える
文体・語調
- •「〜を使用します」「〜を提供します」の多用を避け、「〜できます」「〜します」など自然な表現にする
- •「このフラグを使用して〜を指定します」のような冗長な説明は、フラグの意味だけを簡潔に書く
- •受動態の多用を避ける（「〜が表示されます」→「〜を表示します」など、文脈に応じて）
- •「非常に」「非常に退屈な」など原文のニュアンスとズレた強調表現を修正
- •同義表現の連続を避け、1文ごとに役割を分ける（冗長な繰り返しを削る）
- •読点が無い長い文は、意味の切れ目に読点を補って読みやすくする
冗長さの排除
- •フラグ説明で同じ意味を2回繰り返す文を削除（例：「設定ファイルのパス。設定ファイルを指定するにはこのフラグを使用します」→「設定ファイルのパス」）
- •「〜するために使用できます」→「〜に使います」「〜用」
- •1文が長すぎる場合は分割する
語彙選択
- •「導入しました」→ 機能追加の文脈では「追加しました」に統一
- •「容易にする」→「簡単にする」「手軽にする」
- •「メカニズム」→「仕組み」（技術文書でも過度なカタカナ語を避ける）
- •「退屈な作業」→ "hard"の訳なら「大変な作業」、"boring"なら「面倒な作業」
- •「開発者フレンドリー」などの直訳的なカタカナ語は「開発者にやさしい」「開発者向け」に置き換える
- •「簡単セットアップ」のような名詞連結は「簡単なセットアップ」「セットアップが簡単」に直す
- •「〜中心の〜」の表現は助詞を補い、「〜を中心にした〜」など自然な言い回しにする
翻訳の正確性
- •英語版と意味が大きく異なる箇所を修正（訳漏れ、誤訳）
- •ただし逐語訳ではなく、日本語として自然に伝わる表現を優先する
技術用語の扱い
- •コマンド名、フラグ名、ファイルパス、URLは翻訳しない
- •コードブロック内は変更しない（コメントの翻訳は許可）
- •「デフォルトは〜」の表記を統一（例：
デフォルト: .dodo.yaml）
表記・記号の統一
- •和文内の括弧、ダッシュなどの記号は全角で統一し、不要な半角スペースを入れない
- •和文中のコマンドやファイル名は前後の助詞やスペースで読みやすさを確保する
- •見出し直後は冗長な導入句を避け、具体語で端的に示す
- •日本語ページの見出しが英語のままなら、必要に応じて自然な日本語にローカライズする
PHASE 3: 検証
- •修正したファイルすべてを再度読み通し、日本語として自然か確認する
- •
dodo checkを実行して設定の整合性を確認する - •エラーがあれば修正して再実行する
出力
修正完了後、以下のレポートを出力する：
- •レビューしたファイルの一覧
- •ファイルごとの主な修正点（カテゴリ別）
- •
dodo checkの結果 - •全体の統計（ファイル数、修正箇所数）
注意事項
- •原文の意図やトーンを壊さないこと
- •コードブロック、フロントマター、技術的な識別子は変更しない
- •過度な意訳はせず、原文に忠実かつ自然な日本語を目指す
- •修正に確信が持てない箇所はユーザーに確認する