なぜ急速に進化するDevToolsはドキュメントのローカライズを避けるのか

ここ数か月間、世界的に採用されている複数のDevToolプロジェクトのGitHub履歴をレビューしました。

これらの多くのチームは、アジア、ヨーロッパ、ラテンアメリカにユーザーがいます。それにもかかわらず、公式ドキュメントは英語のみです。

この記事はUI翻訳ではなく、ドキュメントのローカリゼーションに特に焦点を当てています。

これは単に優先順位の問題でしょうか？
それとも、DevToolsにはドキュメントのローカリゼーションが異常に難しい何かがあるのでしょうか？

この疑問を探るために、Redditに投稿し、いくつかのチームにも直接連絡を取りました。

返答は驚くほど一貫していました。

本当に問うべきことは、なぜDevToolsがドキュメントのローカリゼーションを避けるのかではありません。

むしろ、彼らが試みたときに何が起こるかかもしれません。

1. ドキュメントのローカリゼーションは開発速度を遅らせることがある

DevToolsは高速で進化します。

インストール方法が変わり、
APIは進化し、
機能は追加されたり削除されたりします。

ドキュメントは静的な参照資料ではありません。
それは製品の一部です。

製品が変われば、ドキュメントもそれに伴って変わらなければなりません。

複数言語を追加するということは、単に翻訳ファイルを追加するだけではありません。
継続的な同期の問題が生じます。

すべてのドキュメント更新は、言語間で正確でなければなりません。
翻訳、レビュー、検証はリリースの速度に合わせて進む必要があります。

専任のローカリゼーションリソースがないチームにとって、これはすぐに重荷になります。

問題は翻訳が可能かどうかではありません。

問題はドキュメントのローカリゼーションがリリースの速度についていけるかどうかです。

迅速なリリースが重要なチームにとって、ドキュメントを英語ファーストに保つことは合理的な選択です。

2. 開発者は英語のドキュメントに慣れている

もう一つの一般的な議論は単純です。

開発者は一般的に英語のドキュメントを読むことに慣れています。

Stack Overflow、GitHub、そしてほとんどのRFCは主に英語で運営されています。

指標の観点から見ると、多言語ドキュメントが明確な収益効果につながるとは限りません。

効果が明確でなければ、コア製品の改善を優先するのは理にかなっています。

しかし、もっと複雑な面があります。

英語を読むことは、無理なく理解することとは異なります。

オンボーディング中に、小さな摩擦が積み重なります：

インストール手順の誤解
設定詳細の読み誤り
公式ドキュメントではなく古いブログ記事の利用

これらの問題は一つの指標としてはほとんど表れません。時間の経過とともに、非英語圏の地域での活性化の質、サポート負担、ユーザーの信頼感に影響します。

したがって、ドキュメントのローカリゼーションは二者択一の問題ではありません。

それは短期的な速度と長期的なグローバルな深さのトレードオフです。

3. 繰り返されるパターン

多くのリポジトリに共通するパターンがあります。

コミュニティメンバーがドキュメントの翻訳を始める。
いくつかの重要なファイルがローカライズされる。
オリジナルのドキュメントが急速に変更される。
翻訳が同期を失う。
古いバージョンが検索エンジンに残る。
チームは公式にドキュメントのローカリゼーションをサポートしなくなる。

この決定は運用的に理解できます。

しかし、その後に重要なことが起こります。

ローカライズされたコンテンツは存在し続けますが、公式の管理外となります。

非公式のガイドが特定地域で広く利用されるようになります。
インストール手順が最新リリースと合わなくなります。
サポートの会話が標準化しにくくなります。

このパターンは二つのことを示しています。

ローカライズされたドキュメントに対する本当の需要があること。

しかし、従来の管理方法はスケールしないこと。

問題は言語ではありません。

同期の問題です。

flowchart TD
    A[英語ドキュメントの変更]
    B[翻訳にずれが生じる]
    C[古くなったガイドが流通する]
    D[サポートの摩擦が増す]
    E[ローカリゼーションの優先度が下がる]

    A --> B --> C --> D --> E
    E --> A

4. 残された課題

これらすべてを考えると、急速に進化するDevToolsでドキュメントのローカリゼーションを避けるのは理解できます。

速度が重要で、
リソースは限られ、
同期コストも現実的です。

しかし、一つの疑問が残ります。

もし多言語ドキュメントがリリースごとに遅れることなく常に同期されたままでいられたらどうでしょうか？

もし最大の課題が高速リリースに同期することなら、本当の問題は翻訳そのものではありません。ドキュメントのローカリゼーションがリリースパイプラインにどう組み込まれるかです。

もしチームが英語でドキュメントを書き続けながら、ローカライズ版が自動的に各リリースに合わせて同期され続けられたら？

その場合、ドキュメントのローカリゼーションは速度と競合することはありません。
むしろ速度とともに進みます。

Co-op Translator OSSを通じて14のMicrosoftオープンソースリポジトリでドキュメントローカリゼーションの自動化に取り組む中で、同期が別のメンテナンス作業として扱われるのではなく、リリースワークフローに直接組み込まれる方法を検証してきました。

一つのパターンが明らかになりました。

ほとんどのDevToolチームは、グローバルユーザーを気にしていないからドキュメントのローカリゼーションを拒んでいるわけではありません。

彼らが躊躇するのは、手動での同期がスケールしないからです。

未解決の問題は、ローカリゼーションが常に遅れる並行プロセスではなく、リリースに連動するシステムになり得るかどうかです。

もし同期がリリースシステムの一部になるなら、速度と多言語アクセシビリティのトレードオフはまったく異なるものになるかもしれません。