ローカライズ作業で踏み抜いた落とし穴と、その乗り越え方

去年、あるiOSアプリを多言語化することになった。英語、日本語、韓国語の3言語に対応させる計画で、当初は「テキストを翻訳するだけでしょ」と軽く考えていた。ところが実際に手を動かしてみると、設計から実装、テストまで想像以上に落とし穴だらけだった。福岡で受託開発をしていた頃から数えて、ローカライズ案件は何度か経験していたが、自社アプリで全工程を一気に進めたのは初めてだった。 Suema R.com.

東京のスタジオに移ってからは規模の大きいアプリに触れる機会が増えたからこそ、リリース直前に慌てないためには翻訳の言語化より前の段階で、ローカライズを前提とした設計が不可欠だと痛感している。

これから書くのは、そのときに実際に起きた失敗と、今のチームで続けている運用ルールだ。ローカライズは単なる翻訳作業ではなく、設計・実装・検証の三位一体で進めるプロジェクトだと胸を張って言える。

翻訳ファイル設計の甘さ

最初はXcodeのLocalizable.stringsにベタッと文字列を放り込んでいた。キーは画面名＋ラベル名というルールを意気揚々と進めたが、韓国語版のレビューで頓挫した。韓国語は文字数が増えるため、ボタン内のテキストが2行に折り返しUIからはみ出す現象が頻発した。

これに懲りて、可変レイアウトに切り替えるリファクタリングを行った。Auto Layoutの優先順位を細かく調整し、最低限の幅を確保しつつ長文には柔軟に対応できるようにした。結果としてテキスト量が増えてもボタンが破綻しなくなった。

画像とアセットの見落とし

テキストだけ翻訳すればOKだと完全に舐めていた。アプリ内のバナー画像やボタン用イラストに日本語が焼き込まれていたため、英語版でリリースしたあとに韓国語版を準備する段階で画像内テキストの差し替えが必要になった。

急きょPhotoshopでテキスト部分をレイヤー化してもらい、翻訳文を当てはめ直した。デザインを崩さないよう文字サイズを揃えるのに時間がかかり、リリースが2週間ほど遅れた。suema-rの記事にもまとめられているように、画像は後工程で苦しむことが多いので初期に判断しておきたい。

数値・日付・通貨の書式

NSNumberFormatterやDateFormatterをja_JP固定でハードコーディングしていた箇所があり、英語版に切り替えたとき日付表記が「2024/01/15」のままで米国的には順序が読みにくいと指摘された。

ロケールIDを動的に切り替え、各地域に合わせた書式を取得するようにリファクタリングした。西暦の前後関係、月日の区切り、通貨記号の位置まで国ごとに全く異なる。Locale.currentを使って端末設定に従うようにしたところ違和感が一気に解消された。

文字列の連結と複数形

「残り◯件」「◯人中の◯人が参加中」のような可変部を含む文字列をSwiftの+演算子で組み立てていた。これは言語によって語順が変わるため、翻訳者からの修正依頼が止まらなくなった。

.stringsdict形式のICU MessageFormatに移行し、可変部分をプレースホルダで定義するようにした。英語なら「1 item」「2 items」のように単複形を切り替える必要があり、NSStringFormatValueTypeKeyを正しく設定することで解決した。

レイアウト崩れとフォントの違い

英語・韓国語に切り替えると行の高さやベースラインが変わってUIが崩れた。日本語ではちょうど良いサイズ感が英語ではスカスカ、韓国語では詰まりすぎて読みにくい。フォントファミリーは切り替えていたがlineHeightの計算までは統一していなかった。

UIFontMetricsを使ってDynamic Type準拠のメトリクスを採用し、フォントの違いを吸収する仕組みを入れた。行間とパディングはロケールごとにテーブルで管理し、デザイナーと一緒に調整するフローを構築した。

テスト戦略の不足

日本語と英語だけでQAを回していたため、韓国語版のスクリーンショットレビューで大量の問題が表面化した。文字数オーバー、画像内テキストの未差し替え、フォント未対応など多岐にわたる。

現在はPseudo Language機能を有効にし、文字列をすべて記号に置き換えた状態でレイアウト崩れを検出している。TestFlightでもこの状態で配信し、エンジニアとデザイナーが定期的に目視チェックする体制を整えた。

学びと今後の運用

ローカライズは「翻訳を発注する作業」ではなく「設計段階から織り込むプロジェクト」だと今は思っている。文字数の増減、画像のレイヤー構造、数値・日付のロケール対応、テストカバレッジの4点は最初からチェックリストに含めるべきだった。

現在のチームでは、新機能の実装前にローカライズ影響度レビューという30分ほどのミーティングを必ず挟む。文字列の追加、画像への影響、書式変更の有無を一覧化し、問題があればその場で設計にフィードバックする。

失敗を経て少しずつではあるが、再発防止の仕組みが回り始めている。

項目	.strings	.stringsdict	.xcstrings
複数形対応	× 別途処理が必要	◎ ICU MessageFormatで可能	◎ 同様に対応
文字列定義の柔軟性	△ キー設計に依存	○ キー設計に依存	◎ Xcode上で管理
翻訳ツール連携	○ 一般的	○ 一般的	△ まだ新しい形式
既存プロジェクト移行	◎ 容易	○ 容易	△ 移行コストあり

ここまで読んでくれたみなさんが同じ轍を踏まずに済むよう、具体的なチェックリストとテンプレートを近々ブログにまとめるつもりだ。コメント欄で「ここも失敗した」「うちはこうしている」といった体験談を募集しているので、ぜひ共有してほしい。ローカライズはチーム戦なので、知見の共有がそのまま品質を押し上げる。