【ITニュース解説】From Build-Time to Real-Time: A Better i18n Workflow for React

ウェブサイトやアプリケーションを世界中の多くのユーザーに使ってもらうためには、様々な言語に対応する、いわゆる「多言語対応」が欠かせない。これは「国際化（Internationalization、略してi18n）」と「ローカライゼーション（Localization、略してL10n）」と呼ばれ、異なる言語や文化に合わせてソフトウェアを調整する作業を指す。この中で特に重要なのが、アプリケーションに表示されるテキスト（翻訳）をいかに効率的に管理するかという点である。

多くのプロジェクトでは、多言語対応の仕組みをシンプルに導入することから始める。Reactアプリケーションの場合、react-intlやreact-i18nextのようなライブラリをインストールし、英語ならen.json、日本語ならja.jsonといったファイルに各言語の翻訳テキストを記述する。例えば、en.jsonには「ホーム」を意味する"sidebar.home": "Home"といった形で、翻訳のキーと実際のテキストを記述し、アプリケーションのコード内でそのキーを使って表示する仕組みである。これは手軽で分かりやすく、プロジェクトの初期段階では十分に機能する。しかし、プロジェクトが成長し、翻訳の量が増えたり、翻訳の修正が頻繁に発生したりすると、このシンプルな管理方法には様々な問題が生じてくる。

例えば、翻訳テキストのちょっとした誤字脱字を修正するためだけに、開発者がアプリケーションのコードを修正し、プルリクエスト（コード変更をチームに提案する仕組み）を作成し、レビューを経て、最終的にアプリケーション全体を再デプロイする必要が出てくる。これは非常に手間がかかる作業であり、特に翻訳の頻度が高い場合や、翻訳チームが開発チームに修正を依頼しなければならない状況では、翻訳の更新が遅れる原因となる。また、複数の開発者が同時に翻訳ファイルを変更しようとすると、マージコンフリクト（異なる変更がぶつかり合うこと）が発生し、その解決にも時間が取られてしまう。翻訳という「コンテンツ」を、アプリケーションの「コード」の一部として扱っていることが、こうした非効率性の根本原因にあるのだ。

この問題に対処し、より効率的な翻訳管理ワークフローを構築するために、いくつかの進化の段階が考えられる。

最初の大きな改善は、翻訳をアプリケーションのソースコードから切り離し、独立した「データ」として扱うことである。これは「ビルド時の翻訳自動取得」という形で実現される。このアプローチでは、POEditorやLokalise、TnT（Terms and Translations）のような専用の翻訳管理プラットフォームを利用する。翻訳チームは、これらのプラットフォームが提供する使いやすいウェブダッシュボード上で、直接翻訳テキストの入力や修正を行う。開発者は、アプリケーションをビルドする（公開可能な形に変換する）直前に、簡単なスクリプトを実行して、これらのプラットフォームから最新の翻訳データを自動的にダウンロードし、プロジェクト内に配置する。

この仕組みを導入することで、以下のようなメリットが得られる。まず、翻訳の変更は翻訳管理プラットフォーム上で行われるため、開発者は翻訳ファイルを手動で修正する必要がなくなる。これにより、開発者の作業負担が軽減され、翻訳ファイルにおけるマージコンフリクトの問題も発生しなくなる。次に、アプリケーションのビルドプロセスにこのスクリプトを組み込むことで、デプロイされるアプリケーションには常に最新の翻訳が反映されるようになる。これは、継続的インテグレーション・デリバリー（CI/CD）と呼ばれる自動化された開発・デプロイパイプラインと非常に相性が良い。そして最も重要な点は、翻訳データが翻訳管理プラットフォームに一元的に集約される「単一の真実（Single Source of Truth）」が確立されることである。これにより、Gitリポジトリはコードのみを管理するクリーンな状態を保てる。

さらに進んだ理想的な形が、「クライアントサイドでのリアルタイム更新」である。これは、アプリケーションをデプロイし直すことなく、翻訳テキストの変更を即座にユーザーに反映させることを目指すものである。このアプローチでは、翻訳ファイルをアプリケーションのバンドル（配布ファイル）に含めることをやめる。代わりに、ユーザーのブラウザがアプリケーションを実行する際に、翻訳管理プラットフォームから直接翻訳データを取得する仕組みを構築する。

具体的なワークフローは次のようになる。アプリケーションがユーザーのブラウザで読み込まれると、まずブラウザのlocalStorage（ウェブサイトが少量のデータをユーザーのコンピュータに保存するための機能）に保存されている翻訳データと、その最終更新日時をチェックする。もしデータが存在すれば、すぐにその翻訳を表示し、ユーザーはアプリを速やかに多言語で利用できる。これと並行して、アプリケーションはバックグラウンドで翻訳管理プラットフォームに対し、現在の言語の翻訳が「いつ最終更新されたか」という情報だけを問い合わせる。これは非常に軽量な通信で、データ転送量を最小限に抑える。

アプリケーションは、プラットフォームから取得した最終更新日時と、localStorageに保存されている日時を比較する。もしプラットフォーム上の翻訳が新しいことが判明すれば、その時初めて、最新の翻訳データ全体をプラットフォームからダウンロードする。ダウンロードされた新しい翻訳データと、その最終更新日時はlocalStorageに保存され、次にユーザーがアプリケーションを開いた際には、最新の翻訳が自動的に表示されるようになる。この仕組みにより、開発者がデプロイ作業を行うことなく、翻訳チームやコンテンツ担当者が行った変更が、数分以内にはユーザーに届けられるようになる。

このリアルタイム更新のモデルは、翻訳管理プラットフォームが「翻訳のブランチ機能」を提供することで、さらにその真価を発揮する。これはGitのようなバージョン管理システムに似ており、例えば「開発ブランチ」と「本番ブランチ」のように、翻訳テキストの異なるバージョンを管理できる機能である。開発中の新機能に関する翻訳は開発ブランチで管理し、ステージング環境（本番環境の前にテストを行う環境）のアプリケーションは開発ブランチの翻訳を参照するように設定できる。一方、実際に公開されている本番環境のアプリケーションは、本番ブランチの翻訳を参照する。新機能のリリース準備が整ったら、プロジェクト管理者が翻訳管理プラットフォームのダッシュボード上で、開発ブランチの翻訳を本番ブランチにマージするだけで良い。このマージが行われると、本番ブランチの最終更新日時が変更されるため、次にユーザーが本番アプリケーションを開いたとき、アプリケーションは自動的に新しい翻訳を検知し、ダウンロードして表示する。

これにより、誤字の修正や新しいテキストの追加といったコンテンツに関する変更は、アプリケーションのコードデプロイとは完全に独立したサイクルで管理・公開できるようになる。開発者はコード開発に専念でき、翻訳者やコピーライターは自由にコンテンツを更新できる。管理者はこれらの変更をレビューし、承認・マージすることで品質管理も可能となる。コンテンツの更新が即座に、かつ安全に実行できる、非常に効率的で協力的なワークフローが実現するのだ。

このように、Reactアプリケーションの翻訳管理は、シンプルなローカルファイル管理から始まり、ビルド時の自動化、そして最終的にはクライアントサイドでのリアルタイム更新とGitライクなブランチ管理へと進化させることで、堅牢でスケーラブル、そして非常に効率的なプロセスを構築できる。これにより、開発者の負担を大幅に軽減し、翻訳チームやコンテンツ担当者の作業をスムーズにし、最終的には世界中のユーザーに常に最新で正確な多言語コンテンツを提供できるようになるのである。