KINTOテクノロジーズにおける言語ローカライゼーション（後編）

再生速度

AI が生成した要約です。正確な内容は本文をご確認ください。

要約を読む

翻訳管理のためのExcelを使い続けた結果、3つの大きな課題が生じていました。そのうちの1つは、文脈が欠落していることでした。 Excelにはデザインや使い方の情報がないため、翻訳者はただテキストをコピーするだけになり、適切な翻訳ができませんでした。 2つ目は、翻訳内容がどこにも記録されていないことでした。翻訳した内容がTMSに登録されないため、過去の翻訳を確認できず、同じ言葉でも「reservation」と「booking」といった誤った変更が起きる可能性がありました。 3つ目は、開発者が手作業でコードにコピペするためのミスリスクでした。その結果、誤字脱字やバグが生じるリスクが高まり、品質が下がるという問題がありました。この課題を解決するために、Lokaliseという翻訳管理ツールを導入しました。 Lokaliseではすべての文言を1か所で管理でき、過去の翻訳データも記録されるため、一貫性が保たれます。また、GitHubに接続できるため、開発者が新しい機能を作成した際、自動的にそのキーがLokaliseにプルされ、翻訳者が新しい文言を確認できます。これにより、開発者と翻訳チームの作業時間がそれぞれ30％短縮されました。デザインツールのスクリーンショットをLokaliseにインポートできるのも大きなメリットです。翻訳者は実際にどこに文言があるかを視覚的に確認できるため、文脈を考慮して翻訳できます。これにより、Excelのような単純な入力ではなく、実際の使い方を踏まえた翻訳が可能になりました。今後のステップとして、GitHubのリポジトリが増えるにつれて、1つずつプルリクエストを行うのが重いという問題があります。そこで、社内で中間的な管理ツールを作成し、すべてのファイルの更新を一元管理できるようにする計画があります。さらに、ブランドガイドラインと同じように、スタイルガイドを作成し、すべての言語でブランドのトーンを維持できるようにします。これにより、翻訳業者間のギャップがなくなり、一貫した体験が実現できます。

 はじめにKINTOテクノロジーズにおけるローカライゼーションに関して、後編となる今回の記事では、これまでチームが行ってきたことをご紹介します。
 課題前回の記事では、ソフトウェア翻訳が翻訳キーと対応するバリュー（文言）のペアで保存されることが多い、と説明しましたが、今回はこのデータをどう管理しているかについて説明します。キーと文言のペアがある前提として、ローカライゼーションのプロジェクトマネージャーはベース言語（KINTOの場合は英語）をどのように扱い、翻訳業者（Language Service Provider ＝LSP）に翻訳依頼すべきでしょう？
私自身、フリーランスで翻訳を行っていた経験がありますが、その中でもエンジニアがExcelで翻訳キーとソース言語の文言を2列で作成し、それをターゲット言語の数だけ複製して翻訳に回すというのはよくあることでした。しかし、この管理方法には、大きく3つの課題があります。
文脈や言葉の前後関係の欠落
一元管理できず、将来的な不整合が起こりうる
人為的ミスが起こりやすい
1つ目の課題として、Excelシートは翻訳者にとっては何の脈絡もない単純なテキストの羅列です。指定のテキストがボタンなのかどうか？デザイン上どれくらいのスペースがあるか？プレゼンのようなストーリーテリングの場合、どのような場面で誰が誰に向かって話しているか？適切に翻訳するにはこのような情報が必要です。
2つ目の課題は、翻訳管理システム（TMS）などに登録しない限り、翻訳した、文言はどこにも記録されないということです。記録がないため、以前どのように翻訳したかを参照することが難しく、以前は「reservation」としていたものを今回は「booking」としてしまうなど、のちのちサービスのクオリティやカスタマーエクスペリエンスに矛盾が生じる可能性があります。ソース言語（英語）だけでもこの課題は発生するので、これが翻訳対象言語の数だけ不整合が起こりうることを想像してみてください。Excelでは追いきれません。
3つ目の課題は開発側の人為的ミスが起こるリスクが高いことです。翻訳文言がExcelファイルに保存されている場合、最終的には手作業で1つずつソースコードにコピペする必要があります。（前回記事の例では「localizable.strings」ファイル）そのため、コピペミスや誤字脱字、さらには最終チェックを行うQAが適切に行われないと、バグが発生する可能性があります。
 どのように解決したかこれらの課題を解決するために、Excelでの翻訳管理を行わず、Lokaliseという専用のツールを導入することにしました。
_Lokalise_は翻訳タスクを管理できる翻訳管理システムで、すべての文言を1か所で集中管理できます。また、翻訳メモリ（過去にどう翻訳したかを記録するデータベース）の整備や、全てのプロダクトに適用できる用語集の作成ができるのも、このツールのメリットです。また、ソースファイルが保存されているGitHubに接続する機能もあり、開発者が開発した新しい画面や新しい機能のキーを「プル」し、その後、ターゲット言語の翻訳キーと文言のペアをGitHubにプルリクエストを作成して「プッシュ」可能です。
このようにプロセスを自動化することで、生産性が向上するだけでなく、開発者とローカライズチーム双方の作業時間を短縮することができます。さらに、一貫したクオリティを保ちながら、条件の整合性を確保し、正確にエンジニアに引き渡すことも可能です。_Lokalise_を使用するもう一つの大きなメリットは、Adobe XDなどのデザインツールから_Lokalise_に各用語のスクリーンショットをインポートできることです。これによって、翻訳者はツールで翻訳する際に視覚的に対象文言がどこにあるかわかるので、文脈などを考慮して翻訳することができます。情報量の少ないExcelシートにやみくもに入力するようなことはありません。
以下は、我々が開発しているGlobal KINTO App (GKA)の_Lokalise_導入前と導入後のフローチャートです。iOSとAndroidの両方で利用できるようにするため、ファイル変換にも対応する必要がありました。また、エクスポートする際のフォーマット変換も_Lokalise_が行ってくれるので、工数が節約できます。
 Next Step我々の次のステップとして、スケーラビリティを検討したいと考えています。ソースファイルの更新は_Lokalise_で自動化できましたが、各ファイルへのプルリクエストは1つずつ行うため、GitHubのリポジトリや製品の数が時間とともに増えていくと、すぐに重い作業になってしまいます。_Lokalise_とGitHubの中間的な存在として、社内で小規模な管理ツールを作成し、ソースファイルに必要な更新を伴うプルリクエストを一元管理できるようにすることを、解決策のひとつとして考えています。
また、QAプロセス強化の一環として、既存のブランドガイドラインと同様に、一連のスタイルガイドを作成する計画もあります。スタイルガイドによって、翻訳業者（LSP）に依頼した翻訳でも、翻訳者間、あるいは言語間のギャップなく、ブランドのトーン＆マナーを維持したまま、わかりやすく翻訳することができるようになります。
また、世界各国のKINTOサービスに我々のローカライゼーションプロジェクトを_横展開_する可能性もあり、まだまだ今後のアイデアは尽きません。これらについては、後日別の記事などでお話するかもしれませんが、まずは、私のローカライゼーションの記事に興味を持っていただいてありがとうございます！翻訳や言語ローカライゼーション、他言語化というトピックに関して、少しでも心をくすぐれていれば何よりです。次にアプリをダウンロードしたり、動画配信サービスを利用したり、ゲームをする際には、多言語コンテンツがいかに技術的に複雑なことを行っているか、ぜひ注目してみてください。