目次
モバイルアプリのローカライゼーション：iOSとAndroidのベストプラクティス
重要なポイント
- iOSは
.stringsと.stringsdictファイルを使用し、Androidはres/values-{locale}/ディレクトリ内のstrings.xmlを使用します - App Store Optimization (ASO) では、各市場向けにローカライズされたメタデータ（タイトル、説明、キーワード、スクリーンショット）が必要です
- RTLレイアウトのサポートは、カスタムビューやアニメーションを含むすべての画面でテストする必要があります
- Over-the-Air (OTA) 翻訳アップデートにより、新しいアプリバージョンを提出することなく翻訳を修正できます
プラットフォーム固有のローカライゼーション
iOSのローカライゼーション
iOSは各ロケール用に.lprojディレクトリを使用します：
en.lproj/ Localizable.strings Localizable.stringsdict InfoPlist.strings de.lproj/ Localizable.strings Localizable.stringsdict InfoPlist.strings
主要ファイル：
- Localizable.strings — UIテキスト用のキーと値のペア
- Localizable.stringsdict — 複数形ルール（複雑な複数形を持つ言語に不可欠）
- InfoPlist.strings — アプリ名とパーミッションの説明
Androidのローカライゼーション
Androidはロケール修飾子付きのリソースディレクトリを使用します：
res/ values/strings.xml (デフォルト/英語) values-de/strings.xml (ドイツ語) values-ja/strings.xml (日本語) values-ar/strings.xml (アラビア語)
Androidのリソースシステムは、デバイスのロケールに基づいて自動的に正しいファイルを選択します。複数形にはpluralsリソースを、リストにはstring-arrayを使用します。
ローカライズされたアプリのApp Store Optimization (ASO)
各ターゲット市場向けにこれらの要素をローカライズします：
| 要素 | iOS App Store | Google Play |
|---|---|---|
| アプリ名 | 30文字 | 30文字 |
| サブタイトル | 30文字 | 80文字（短い説明） |
| 説明 | 4,000文字 | 4,000文字 |
| キーワード | 100文字 | 説明内 |
| スクリーンショット | 最大10枚 | 最大8枚 |
| プレビュー動画 | オプション | オプション |
市場ごとにキーワードをリサーチしてください — 英語のキーワードをそのまま翻訳しないでください。
RTL言語サポート
アラビア語、ヘブライ語、その他のRTL言語の場合：
left/rightの代わりにleading/trailing制約を使用します（iOS）- レイアウトで
left/rightの代わりにstart/endを使用します（Android） - ナビゲーションアイコンをミラーリングします（戻る矢印、リストのインデント）
- 双方向テキストをテストします（RTLとLTRの混在コンテンツ）
- カスタムビューがレイアウト方向を考慮していることを確認します
Over-the-Air翻訳アップデート
OTAシステムにより、完全なアプリリリースなしに翻訳を更新できます：
- 翻訳エラーを即座に修正する
- コード変更なしに新しい言語を追加する
- コンバージョン最適化のために翻訳のA/Bテストを行う
- ユーザーのアプリ更新疲れを軽減する
モバイルアプリ翻訳サービス：アプローチの比較
適切なモバイルアプリ翻訳サービスの選択は、チームの規模、予算、品質要件によって異なります。3つの主要なアプローチの内訳を以下に示します。
手動翻訳
手動翻訳では、専門の翻訳者や代理店を雇い、アプリの文字列を1言語ずつ翻訳します。このアプローチは、特にマーケティングコピーやユーザー向けコンテンツにおいて高い言語品質を提供しますが、遅くてコストがかかります。納期は数日から数週間単位で計られ、複数の言語にわたって複数の翻訳者を調整すると、プロジェクト管理のオーバーヘッドが発生します。
自動機械翻訳
スタンドアロンの機械翻訳サービス（Google Translate API、DeepL API、Azure Translator）は速度と低コストを提供します。UIの文字列やドキュメントの初稿作成には適していますが、出力にはプロダクトコンテキストが欠けています。「Set」というボタンラベルは、UIのどこに文字列が表示されるかの認識なしに、動詞（設定する）ではなく名詞（コレクション）として翻訳される可能性があります。自動MTは本番環境に出荷する前に人間によるポスト編集が必要です。
プラットフォームベースのアプリ翻訳サービス
プラットフォームベースのアプリ翻訳サービスは、自動化とワークフロー管理を組み合わせています。翻訳者とMTエンジンを個別に管理する代わりに、プラットフォームが完全なパイプラインを処理します：文字列の抽出、機械翻訳、人間によるレビューのルーティング、翻訳メモリ、およびコードベースへの納品。
Better i18nはこのモデルのために構築されています。React Nativeアプリ向けのExpo SDK（@better-i18n/expo）を提供し、App StoreやGoogle Playを通じて再デプロイすることなくOTA翻訳アップデートを可能にします。プラットフォームのAI翻訳エンジンはプロダクトグロッサリーとUIコンテキストを理解し、アプリ内の各文字列がどこに表示されるかを認識した翻訳を生成します。翻訳は300以上のエッジロケーションと50ミリ秒未満のロード時間を持つCDN経由で配信されるため、ユーザーは更新された翻訳を即座に確認できます。
アプリ翻訳サービスを評価しているチームにとって、重要な質問は、一度限りの翻訳ベンダーが必要か、リリースサイクルに追いつく継続的な翻訳パイプラインが必要かということです。アプリが定期的に新機能をリリースする場合、プラットフォームアプローチにより、手動およびスタンドアロンMTワークフローを遅らせる調整オーバーヘッドがなくなります。
モバイルローカライゼーションのよくある間違い
- リソースファイルではなくコード内のハードコードされた文字列
- 長い翻訳で崩れる固定幅のUI要素
- 複数形の無視 — 多くの言語には単数/複数以上の形があります
- アプリストアのリスティングにおける未翻訳のスクリーンショット
- アラビア語とヘブライ語市場向けのRTLテストの欠如
よくある質問
何言語でローンチすべきですか？ 収益またはユーザーベースで上位5〜10の市場から始めてください。一般的な最初のターゲット：英語、スペイン語、フランス語、ドイツ語、日本語、中国語、韓国語、ポルトガル語。
アプリの文字列に機械翻訳を使用すべきですか？ 機械翻訳は初稿を提供できますが、UIの文字列はコンテキストの正確さのために人間によるレビューが必要です。コンテキストのない短い文字列はMTにとって特に難しいです。
動的コンテンツのローカライゼーションはどのように処理しますか？ 動的コンテンツ（プッシュ通知、アプリ内メッセージ）にはサーバーサイドローカライゼーションを使用します。クライアントサイドローカライゼーションは静的UIを処理します。TMSは両方のワークフローを管理できます。
日付、時刻、数値のフォーマットはどうですか？
デバイスのロケールでプラットフォームフォーマッター（iOSのDateFormatter、AndroidのDateFormat）を使用してください。日付や数値を手動でフォーマットしないでください。
