なぜ私たちはLocalizeflowを作ったのか

技術ドキュメントは生きたシステムである

技術ドキュメントは製品が進化するのに合わせて継続的に進化します。
あらゆる機能追加、更新、API変更はドキュメントの更新を必要とし、その更新は元のソースだけでなくすべての言語に反映されなければなりません。

テキストの翻訳は簡単な部分です。
翻訳済みのバージョンを一貫して最新に保つことが本当の課題です。

実際には、多言語ドキュメントを維持することは常に次のような作業の連続を生み出します：

ドキュメントが増えれば増えるほど、この運用負荷は重くなります。

複数のドキュメントプロジェクトを自分で管理した結果、ある結論は避けられませんでした：
ドキュメントの維持は翻訳よりもはるかに難しい。

2025年にFastAPIチームは、コミュニティ主導の翻訳PRに頼るのをやめ、内部の自動化パイプラインに移行すると発表しました。

これは示唆的でした。
問題は一つの大きなオープンソースプロジェクトに限ったものではありません。多言語ドキュメントを維持するすべてのチームが直面する普遍的な課題を反映しています。

大規模プロジェクトは内部システムを構築できます。
しかしほとんどのチーム、小規模OSSメンテナ、初期段階のスタートアップはできません。

Localizeflowはこの現実に応えるために作られました。

Localizeflowは単なる翻訳ツールであることを目的としていませんでした。

望んだのはドキュメント更新がトリガーとなりGitHub内で自動的にすべてが流れるシステムです：

GitHub Appを一度インストールするだけ。
カスタムスクリプトは不要。
手動でディレクトリ管理も不要。

ドキュメントの変更時に起動する完全なパイプライン。

ほとんどの翻訳ツールは文章単位で動作します。
しかし技術ドキュメントは文章の羅列ではありません。Markdown、メタデータ、コードサンプル、図、テンプレートの構造的な組み合わせです。

Localizeflowはドキュメントの構造レベルで変更を評価し、それに応じて出力を再生成します。

差分は大きくなることもありますが、利点は明らかです：

複数の実際のプロジェクトで、この方法がはるかに信頼性が高いことが証明されました。

LocalizeflowはCo-op Translatorエンジンを基盤としています。
これは1年以上にわたりGitHub上の実際のドキュメントを翻訳・維持する中で開発されたシステムです。

APIのラッパーではありません。
マイクロソフトのいくつかのオープンソースドキュメントパイプラインで利用されている、本格的な実運用用エンジンです。

含まれる機能：

これらの機能は実際のドキュメントワークフローが必要としたからこそ作られました。

Astro、Hugo、Docusaurusなどのドキュメントエンジンが広まるにつれ、コンテンツの量と複雑さは増しています。
ドキュメントの最新化は製品の競争力の一要素です。

Localizeflowはこのニーズが今や不可欠だからこそ存在します。

Co-op Translatorの運用を通じて明らかになった事実。

多くの開発者は依然として自分の母国語による高品質ドキュメントにアクセスできていません。

ドキュメントは製品の一部です。
情報が遅れたりアクセスしにくかったりすると、学習が遅れ、フィードバックループが長くなり、製品採用率が下がります。

Localizeflowのミッションはシンプルです：

どのチームも自分で翻訳システムを構築する必要があってはならない。

DevRel、ドキュメントチーム、SaaS企業、OSSメンテナ、初期スタートアップに関わらず、ドキュメントの更新はすべての言語に自動反映され、必要な変更だけ再生成され、レビュー用の単一PRが生成されるべきです。

多くのチームは最終的に多言語ドキュメントの維持をあきらめます。
ドキュメントが増えて更新頻度が高まると、翻訳はすぐに遅れてしまいます。

Localizeflowはその壁を取り除くことを目指します。

単に翻訳を簡単にするだけではありません。
翻訳されたドキュメントの維持を持続可能にします。