🇹🇭REALITY海外対応のあれこれ🇯🇵

2020年10月27日 17:29

2020年10月5日、めでたくREALITYアプリは、タイのアプリストアにて配信開始となりました！🎉🎊🥳
それに先立ち、REALITYアプリの多言語対応など、海外向けの対応を実施しました。
そのみちのりがどんな感じだったかを、主に開発者の皆さんにむけて共有していきたいと思います！
開発における各部分の具体的実装方法等は、軽い紹介にとどめ、この記事では、

・全体の作業フロー設計と現在の運用方法
・iOSでの海外対応実作業
・開発中に気づいた思わぬ落とし穴や課題

について書いていきたいと思います。

1. ところで、あなたは誰？👀

2019年の10月に新卒入社した、iOSエンジニアの藤井と申します。
今まで、いろんなことに熱中していました。

小学校時代は、レゴブロックとRPGツクール、
中学時代は、ソフトテニスとPSP改造、
高校時代は、アメフトと海外留学、
大学時代は、建築とダンスをゴリゴリにやってました。
いまの趣味は、ラップと、料理と、植物を育てることです。

まだ見たことない場所を、冒険するのが好きです。

入社時のプログラミング経験は、ほぼ0です。Gitの使い方もわかりませんでした。
しかし、僕のチームメンバーや会社の人々は、そんな僕を嫌な顔ひとつせず、じっくり育ててくれています。(ステマではない)

「わからないところに大怪我気にせずどんどんタックルして、込み入ったものを冷静に簡単にしていく」アツさと冷たさを買われて、今回の海外対応にアサインされたと自分では勝手に思ってます。

Tweets by derjapanerr

2. はじめに🎫

読者の皆さまが、「うちのチーム/私の開発に何を持ち帰れるかな」を明確にするために、「プロジェクト開始時、どういう状況だったか」、「どこまでを今回やろうとしたか」、「どこからはやらないことにしたか」を書きます。

🤔 プロジェクト開始時、どういう状況だったか
・それぞれのチームによって海外対応への準備状況はまちまちだった
👉 UI文字列のテキストファイルへの書き出しも、やっていたり、やってなかったり
・翻訳をするためのワークフローや、翻訳者へ共有する方法などのノウハウがなかった
・英語が業務レベルで使えるメンバーの数が限られていたので、英語が堪能ではない人でも最後まで遂行できる業務フローを構築する必要性があった

🎯 どこまでを今回やろうとしたか
・7月末〜9月末の開発期間で、細かな表示の不具合を除いて、全画面で英語と日本語が、言語設定に応じて表示されること。
・今後、複数の地域・言語に展開していく際に、スムーズに機能追加・改修ができる、拡張性を持った全体のワークフローを設計し、運用開始すること

👋 どこからはやらないことにしたか
・英語の複数形対応
👉 実装コストの観点から断念
・地域に合わせた日付の書式対応(yyyy/MM/dd -> MM/dd/yyyy等)
👉 英語圏でも、米国、イギリス、オーストラリアで書式が変わり、かつUI調整に大きな実装コストが割かれることが判明したため断念
・配信中ゲームの翻訳
👉 実装コストの観点から断念
・ギフトの日本語部分の翻訳
👉 日本語に特有の表現の翻訳にリソースがかかり、かつ文化的に翻訳不可能なものが多いため、断念 (画像の掛け軸の日本語部分など)

・海外向けイベントの開催・翻訳
👉 今回の海外展開でどれだけのユーザーが集まるか予想ができないため、断念
・発送が付随するキャンペーンの対応
👉 海外への発送の運用上の手間、法規的制約を考慮し、断念
・公式番組周りの対応・翻訳
👉 運用が煩雑化するため、断念

3. 前準備編🧳

実際のローカライズや翻訳作業に入る前に、今後の運用も含めた作業フロー等をある程度設計しておく必要がありました。
以下は、最終的に今回のリリース時に完成した、「PMが要件を確定してから、それがローカライズされてプロダクトに反映されるまで」のフロー図です。

Copy of 翻訳の発生する作業フロー

翻訳の発生する作業フロー
この業務フローを実現するために、翻訳者・デザイナー/エンジニア間をシームレスにつなぐ管理ツールを設計する必要がありました。
そのため、まず翻訳文字列を管理するためのGoogleスプレッドシートを用意し、翻訳された文字列を、各プラットフォームに合わせて整形されたテキストに書き出すGoogle App Sctriptを実装しました。

スクリプトの実装にあたっては、こちらの記事を大いに参考にさせてもらいました... 圧倒的感謝🙏
現状では、整形されたテキストがクリップボードにコピーされるスクリプトになっており、人間の手でペースト、必要なコミット・プルリクエストを作成するという、ひと手間かかる運用になっています。

書き出し部分のUIはこんな感じです。これを、社内の翻訳チームの方と、担当エンジニアがいじります。
今後、スプレッドシートの記載内容が更新された際に、自動でリポジトリへの差分プルリクエストを生成するようなスクリプトまで組みたいと思っています。

3. 実作業編(iOS)🛣

次に、iOSアプリにおいて実際にした作業を記します。

UI文字列のローカライズ
Storyboard内のUIコンポーネントの文字列を、ViewControllerのIBOutletで管理し、 didSetクロージャーの中でLocalizable.stringsの値をセットするように変更していきました。

@IBOutlet weak var hogeLabel: UILabel! { 
   didSet { hogeLabel.text = R.string.localizable.hogeLabel() } 
}

この作業が一番時間がかかりました。(カウントはしていませんが、100-200箇所あった)
UIの表示を確認し、デザイン上不都合があったら、翻訳者に修正を依頼していきました。
修正内容のほとんどが、画像のように「日本語だと収まっていたけど、英語だとはみ出る」というパターンでした。

修正例: 配信中の設定画面のコメントサイズの翻訳

序数・数字の単位のローカライズ
・日本語で、順位に関する表示が「XX位」と表示される箇所を、英語で「1st, 2nd, 3rd…」のように順序を表す表現ができるようにしました。

   func rankAttributedString() -> NSAttributedString? {
      guard self > 0 else {
          return nil
      }
      if Locale.current.languageCode == "ja" {
          let rankText = String(self)
          let unitString = "位"
          let rankDigitCount = rankText.count
          let unitDigitCount = unitString.count
          let text = rankText + unitString
          let attrText = NSMutableAttributedString(string: text)
          attrText.addAttribute(.font, value: UIFont(name: "HiraginoSans-W6", size: 9), range: NSRange(location: 0, length: rankDigitCount))
          attrText.addAttribute(.font, value: UIFont(name: "HiraginoSans-W6", size: 8), range: NSRange(location: rankDigitCount, length: unitDigitCount))
          return attrText
      } else {
          let numberFormatter = NumberFormatter()
          numberFormatter.numberStyle = NumberFormatter.Style.ordinal
          let text = numberFormatter.string(from: NSNumber(value: self)) ?? ""
          let attrText = NSMutableAttributedString(string: text)
          attrText.addAttribute(.font, value: UIFont(name: "HiraginoSans-W6", size: 9), range: NSRange(location: 0, length: text.count))
          return attrText
      }
  }

「位」でハードコーディングされていた箇所を、端末の言語設定が日本語以外だった場合、標準APIのNumberFormatterを使うようにしました。
func rankAttributedString()という、すでにプロジェクト内に実装されていたStringの拡張関数を改変しました。

・いいね数など、日本語の「万・億」が使われていた箇所を、英語の場合「M(Million), B(Billion)」で区切るように変更しました。(コードは割愛)

クライアントからサーバーへのリクエストヘッダーに、言語情報を付与
Apple公式のローカライズに関するプレゼンテーションに、以下のような記述があります。

「サーバー側とクライアント側などの、アプリの全部分で、コンテンツは一つの言語で統一されているべきである」というガイドラインです。このガイドラインに従うために、クライアントからのリクエストヘッダーに言語情報を付与し、サーバー側からそれに基づいた言語の文字列を返すような実装をしました。
具体的には、サーバーへのAPIリクエストのAccept-Languageヘッダーに、OSの言語情報を付与しました。
端末上で、日本語以外が第一言語に設定されていた場合、リクエストを英語(en)に丸め込んだ上でサーバーに送る処理を、以下のように実装しました。

      var acceptLanguage = "ja"
      if let lang = Bundle.main.preferredLocalizations.first {
          if !lang.contains("ja") {
              acceptLanguage = "en"
          }
      }
      headers[ACCEPT_LANGUAGE] = acceptLanguage
      return headers

アプリ内/サーバー側で地域設定を保持する
地域設定に応じて表示されるイベントや、配信枠を変えるために、設定画面に新項目を追加し、その値がサーバーとアプリ内に保存されるようにしました。
また、タイ地域の場合、Unity上で表示されるフォントの種類も変わります。(タイ語の文字列が標準フォントだけだと文字化けするため)

Info.plistのローカライズ
忘れがちですが、カメラやマイクの使用許可を求めるダイアログの文章は、Info.plistファイルを多言語化して対応します。

曜日、時間表示のローカライズ
・(月) -> Mon. のように表示を変更していきました。
・日付の書式のローカライズは、英語圏でも国ごとに慣習が異なり、サーバー側とフォーマットをあわせることが困難だったので、今回は見送りました。

4. 開発中にハマった落とし穴🕳

😩 AppStore申請で「Missing Purpose String in Info.plist」でのリジェクト
「よっしゃー終わったー申請やァァァ！」という気持ちでAppStore Connectに今回の海外対応バージョンを申請したところ、以下のようなリジェクト文を「お上」から頂きました... 😩

ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. (...)

「NSLocationWhenInUseUsageDescription keyがInfo.plistにないよ」と言われています。
NSLocationWhenInUseUsageDescription keyは、位置情報の許可を求める際の説明文で、Info.plistファイルに記されています。
Info.plistは、実作業編で書いたように、ローカライズされていたので、InfoPlist.stringsに必要な文字列リストが含まれていた、ハズでした。
しかし、

👉 ローカライズした InfoPlist.strings に、Baseの分を含んでいなかった...

バイナリ内に、InfoPlist.strings(English)と、InfoPlist.strings(Japanese)はあったが、
InfoPlist.strings(Base)がないので、レビュワーがInfo.plistを見に行くと、Info.plistファイルにkey自体が存在しない、という扱いを受けました。
InfoPlist.strings(Base)がなかったとしても、コンパイルエラーにはならず、許可を求める表示自体は(English)か(Japanese)のどちらかが表示されるので、バイナリを上げてみないとこの抜けには気づきづらいです。開発者の皆さま、お気をつけください...!!

🤔 Bundle.main.preferredLocalizations.first, Locale.preferredLanguages.first, Locale.current.languageCode の違い

「端末で現在設定されている言語情報を取得する」という機会が何回かありましたが、その方法がタイトルのようにいくつもあり、迷いました。

・アプリが保持している言語ファイルに関係なく、OSの言語設定の第一位の値を、地域情報(画像で言う、-IN)が付いた状態で返すのが、Locale.preferredLanguages.first

・Locale.preferredLanguages.first から、地域情報を抜いた第一位の言語を表示するのが、Locale.current.languageCode

・OSの「言語の優先順位」と、アプリが対応している言語が最初に一致した値が入っているのが、Bundle.main.preferredLocalizations.first

という違いがあります。

例えば、ユーザーの端末言語設定が、タイ語(th) > 日本語(ja) > 英語(en)、地域がUSで、アプリの対応言語が日本語(ja)と英語(en)だった場合、

・Locale.preferredLanguages.first 👉 th-US
・Locale.current.languageCode 👉 th
・Bundle.main.preferredLocalizations.first 👉 ja

というような違いが生まれます。
Locale系の取得方法を使うと、アプリに対応していない言語情報が取得される可能性があるので、その点に留意が必要です。

😩 翻訳者へ、文字列がUI上のどこにあるかを共有するのが大変

翻訳者にリストを共有したが、該当する文字列がUI上のどこにあたるのかがすぐに共有できないことが多々ありました。
今回は、逐一こちらからスクリーンショットを送る運用となってしまいました。
次回の海外対応の際には、スプレッドシート上にUI/UXデザインツールのURLを添付することで、わかりやすくする運用にしようと考えています。
しかし、デザインツール上での名付けのルールがバラバラであったり、UIの検索ができない事情があったりで進んでいないので、まずはそれを解決するところからです。

😩 翻訳がまだ完成していないが、masterブランチにマージだけしておきたい
開発を進めていくにつれ、当然、海外対応プロジェクト以外の機能開発も進みます。
その際、新しいUIが追加されていきます。しかし、スプレッドシートからテキストファイルを書き出す運用に対応しているのは、海外対応プロジェクトのブランチだけです。
そうなると、何か機能開発があるたび、海外対応プロジェクトのエンジニアが、その機能開発で出現したテキストをスプレッドシートに入力し、海外対応プロジェクトブランチに取り込む必要がありました。
この作業に追われ、海外対応自体の作業が進みづらくなったときがありました。
🤔 「とっととmasterブランチに対応した分からマージすればよいのでは？」とお考えになる方もいると思いますが、翻訳が不完全のまま、ユーザーにお届けするわけにもいきません。

そこで、チームのエンジニアがひらめきました。

今回は、日本とタイでとても使用者が少ない、ナイジェリアの地域言語、「イボ語(ig)」の Stringsファイルに英語を書いておき、本番環境で確認する場合、端末の言語をイボ語に設定して確認する、という運用をしました。

余談ですが、イボ語を使っているナイジェリアの「イボ族」の血は、某若手プロ野球選手の方にも流れているようです。もし、REALITYユーザーに彼がいたとしたら、海外対応が既に予測されていたかもしれません...

また、次回に別言語・地域に対しての対応を行う場合は、恐らく他の言語で本番確認を行う予定です。どれにしようかな。

5. おわりに📚

今回の海外対応プロジェクトは、結果として変更範囲が多岐に渡ったので、REALITY開発チームの総力戦となりました。
「ただ翻訳すれば終わりじゃね？」と最初は思っていましたが、全然そんなことはなかったです。
なんとなく、チームが雰囲気で行っていた様々な命名規則やUI実装方法を改めて統一したり、プルリクエストのルール自体に変更を加えたり、はるか古の、開発者が既に転職してしまった部分のコードをローカライズしたりと、
なかなかに骨の折れる仕事でした...

しかし、おかげでチーム全体の団結も高まり、打ち上げはタイ料理の店で死ぬほどトムヤムクンを飲めて、良かったです！！！

次はどの国に対応しようか、今から楽しみにしております！！！