ドキュメント翻訳の再考：翻訳をバージョン管理されたソフトウェア資産として扱う

大規模なドキュメントリポジトリでは、翻訳の問題は滅多に大声で失敗しません。代わりに、静かに失敗し、時間とともに蓄積されます。最近、Co-op Translatorが翻訳を扱う方法について根本的な設計上の決定を下しました。

翻訳はもはや単なる静的な出力ではなく、**「バージョン管理されたソフトウェア資産」**として扱われます。

翻訳が静かに負債になるとき

ほとんどのプロジェクトでは、翻訳は完成した時点で有効と見なされ、誰かが問題に気づくまではそのままです。しかし、原文が進化しコード例が変わると、翻訳された内容は流暢に読めても古くなります。これはもはや翻訳品質の問題ではなく、メンテナンスの問題です。

私達はコアとなる問いを変更する必要がありました：

Co-op Translator 0.16.2以降、翻訳を意図的にバージョン管理された資産として定義しました。これはMarkdownファイルだけでなく、画像、ノートブック、その他の翻訳済み成果物にも適用されます。

新しい仕組みを考案する代わりに、pip、poetry、npmのようなソフトウェア依存管理ツールに目を向けました。依存関係が古くなった場合、それは「誤り」ではなく単に現在のバージョンと同期していないだけです。この論理をドキュメントに適用しました。

これまで翻訳のメタデータはファイル内のコメントとして存在し、断片化して見落としやすいものでした。現在は言語ごとにJSON状態ファイルを用いて、原文のバージョン、翻訳成果物、および同期状態を追跡します。翻訳状態はリポジトリ内で第一級の検査可能な要素になりました。

同じモデルがテキスト以外の資産にも適用されます。原文の画像が変更された場合、翻訳されたバージョンは即座に「同期ずれ」としてマークされます。これによりリポジトリ内のすべてのコンテンツタイプの一貫性が保たれます。

この設計により次のことが可能になります：

翻訳をソフトウェア資産としてモデル化することで、あいまいさは消え去ります。状態が見える化され、メンテナンスが管理可能になります。問いはもはや翻訳ずれが存在するかではなく、**「それを見えるか？」**となります。

参照：