PapermarkはいかにLingo.devでドキュメントのローカライズを自動化したか

Papermarkは、オープンソースのドキュメント共有プラットフォームです。ドキュメントのローカライズに取り組もうとしたとき、チームは多くの開発者向けツール企業と同じ壁にぶつかりました。Next.jsアプリでi18nを正しく機能させることのほうが、翻訳そのものより難しかったのです。

セットアップの壁#

「使えそうな自動化パッケージや自作ツールはひと通り試しました」と振り返るのは、Papermark創業者のIuliia Shnai氏です。「いちばんの悩みは翻訳工程そのものではなく、アプリの構造に合わせてi18nをきちんと動かすことでした。」

これはよくある構図です。多くのローカライズツールは、i18nの基盤がすでに整っていることを前提にしています。翻訳はできても、設定やファイル構造、MDXのパース、フレームワークごとに異なるエッジケースまでは面倒を見てくれません。少人数のオープンソースプロジェクトにとって、ローカライズのセットアップにエンジニアリングの時間を割くことは、そのままプロダクトへのコストになります。

さらに難易度を上げるのがMDXファイルです。Reactコンポーネントを埋め込んだMarkdown形式のドキュメントであるMDXは、JSONのロケールファイルや単純な文字列を扱う標準的なi18nツールとは相性がよくありません。コンポーネントの埋め込み、frontmatter、カスタムタグを含むMDXコンテンツには、別のアプローチが必要です。

何が変わったのか#

Lingo.devの創業者であるMaxが直接コンタクトを取り、PapermarkのNext.jsプロジェクトの設定を支援しました。実装では、チームが行き詰まっていたエッジケースを解消。MDXファイルの処理、next-intlとアプリのファイル構造の兼ね合い、そしてコンポーネントの多いドキュメントから翻訳可能な文字列を抽出する部分まで対応しました。

「この実装は、私たちが想定していなかった多くのエッジケースまでカバーしていました」とShnai氏は語ります。「ローカライズの複雑さを本当によく理解していることが伝わってきました。特に、私たちにとって大きな悩みだったMDXファイルへの対応は印象的でした。」

初日で、ドキュメント80ページの翻訳が完了。Papermarkの製品用語を反映し、リポジトリと接続されたローカライゼーションエンジンが、ドキュメント一式を自動で処理しました。

現在の仕組み#

Papermarkのローカライゼーションエンジンは、コードがpushされるたびに動作します。新しいドキュメントが追加されたり、既存コンテンツが更新されたりすると、エンジンが変更分を自動で翻訳。エンジニアは英語でドキュメントを書くだけで、追加の手順なしにローカライズ版が生成されます。

ここで効いてくるのが、状態を持つ仕組みです。ローカライゼーションエンジンはPapermarkの製品用語をすべてのリクエストをまたいで保持するため、「Data Room」「Link tracking」「NDA flow」といったプロダクト固有の用語も、あらゆる言語で一貫して翻訳されます。最初のページでも100ページ目でも、同じ製品語彙が適用されます。

「翻訳に継続的なエンジニアリング工数はゼロ」。これが目に見える成果です。ただ、その本質は、ローカライズが都度発生する作業ではなく、インフラになったことにあります。