i18n（国際化対応）を自前で対応させた話

i18n対応を自社で設定

オンラインでコンテンツを提供している弊社のシステムである、Alms (Aidemy Business) ではi18nというツールを用いて国際化対応を設定されており日本語と英語で現在受講可能です。Almsで表示されるテキストはエクササイズやテストなどのコンテンツ、UIの2種類で構成されておりユーザのアカウント設定画面より言語設定を変更すると任意の言語で表示されるようになっています。

以前の記事でも触れましたが自社でi18n対応できるようコンテンツ部分は変更されていましたが、UIもi18nを用いて国際化対応しましたので、今回の記事ではこちらについて説明いたします。

これによりi18nに関してより詳しい対応が可能となったので、ここからは以前利用していた外部ツールから自社によるi18n対応に置き換えることにより、可能になったことを技術的な観点からお話していきます。

弊社のAlmsのフロントエンドはReactを使っており、i18nのためにi18nextというライブラリを使用しました。

alms.dev

任意のUIテキストに言語の設定を追加しやすい

外部ツールではスクリプトを読み込むとclient上で表示されたテキストが適宜翻訳されるような仕組みが提供されていました。

日本語のUIを表示するのみだったシステムがスクリプト一行で多言語に翻訳されるため非常に使いやすいものでしたが、翻訳の変更に関して難しい点がありました。それは任意のUIテキストに対して変更を与えたい場合、用意されたUIからしか変更をかけられない点です。

導入当初は翻訳テキストの設定を簡単にできてよかったのですが、詳しい設定（日付設定など）をしたい場合なかなかUI上からではできませんでした。それが今回に関しては言語ごとにjsonファイルを用意しUIテキストに当てはめていくというシンプルな仕組みに変更されたため、カスタマイズ性が向上しました。

翻訳置換がスムーズに実行される

外部ツールではclient側でHTMLとしてrenderされたテキストから別の言語を置換するような仕組みでした。そのため、一瞬日本語が表示されてから英語に翻訳されるようなズレがページごとに発生してしまっていた。

今回の変更では、render前にテキストを置換しclientでテキストを表示するためにユーザは翻訳のズレを感じることがなくなりました。

i18nの運用体験が良くなった

外部ツールではページごとに置換用のテキストが設定されており、それを置換していくものでした。しかし、AlmsはSPAもしくは、URLがチームごとに存在する状況からうまく翻訳が置換されていないテキストが表示される場合がありました。特に開発環境ではうまく表示されないケースがあり、本番環境で確認せざるおえない状況が存在し作業コストが増える状況にありましたが、こちらも今回で特に環境ごとの差異は発生しないため解消されています。

i18n設定後に困った話

今回、i18nextのライブラリを使用し自社でi18nの対応を行ったのですが、少し困った部分が残ってしまいました。それは、コードの可読性と翻訳の追加作業の部分です。

コードの可読性

まず、コードの可読性についてですが、できあがったコードはi18nの実装自体は完了されたのでよいのですが今後運用するとなると可読性の問題がありそうです。

今回、コード上のUIテキストをi18n対応にしてくれる関数に置き換える作業をエンジニア以外の作業者、複数人に担当してもらったため複雑な作業は依頼できませんでした。そこでわかりやすく言語対応を示すkey名として[挿入するコンポーネントファイル名.(数字)]という命名方法で置換をお願いしていました。そのため、今後開発や修正をいれるときに実装されているコード上でkeyがどういうテキストを示すのか、テキストを別ファイルにまとめたのでひと目ではわからないようになりました（コンポーネントと翻訳ファイルのコードを参照する動作が増えた）。

これに関してはそれぞれの翻訳の箇所にfallback（デフォルトの指定されるテキスト）としてテキストを示す、もしくは日本語（英語）のkeyにしてしまうのがよいかなと思います。個人的には2つ目が開発者にとってやりやすそうだなと考えています。しかしどの言語に設定するべきかは少し相談が必要そうなのと、翻訳テキスト（日付、同じテキストに訳が複数ある、テキストが長い）によっては適宜対応が必要そうです。

翻訳の追加作業

また、困った話の2点目の翻訳の追加作業に関してですが、UIテキストが増えたり言語設定が今後増えたときにそれぞれ言語の翻訳ファイルに該当のkeyが示すテキストが網羅して入っているかの確認作業が難しそうだなというお話です。

今回、それぞれの言語の翻訳ファイルにテキストを1000行あたり追加したのでそれぞれのテキストが言語ごとにはいっているかを確認するのは手動では困難です。これに関しては、すべてのkeyにテキストが入っているか、そもそもkeyがあるのかをチェックするスクリプトを作成し、CI上で毎回走らせればいいのではないかなと思っています。

今後

元々利用していた外部ツールは、自社の運用コストを下げることができ国際化対応を手軽に実施できる、すごくよいものでした。お金をはらえばプロにも翻訳を頼めるサービスもやっており弊社のシステムとの相性があえばi18nをスケールさせやすいものであったと思います。

しかし、今回は運用コストやカスタマイズ性から自前でi18nを設定しました。これにより言語が増えても対応できるようになり、UIの追加、言語の追加を対応できるような基盤ができました。

今後としては実運用の際に少しつらそうなところが現時点ですでに見えているので、さらに運用の効率化をうまく設定していきたいと思います。