右横書き言語(RTL) — 対応はエンジニアリングの課題であり、翻訳だけでは解決しない

右横書き(RTL)言語を「もう一つの翻訳対象言語」として扱いたくなるかもしれません — 文字列を差し替えてビルドするだけ、と。しかし実際には、RTL対応はレイアウト・テキスト描画・入力処理にまで及び、翻訳ファイルを差し替えるだけでは解決しません。エンジニアリング側の準備ができていなければ、どれほど正確な翻訳であっても、読む向きが逆転したまま崩れたUIの中に置かれることになります。

この記事は、RTL対応にコミットする前に調べておくべきことの概観であり、完全な実装ガイドではありません。詳細はエンジンやテキスト描画スタックによって大きく変わります。

読む向きは問題の入り口にすぎない

アラビア語やヘブライ語などのスクリプトは右から左に書き、読むため、本文テキストはその向きに流れる必要があります。これは分かりやすい半分です。分かりにくい半分は、左横書きの読者向けに作られたUIが、テキストの向き以上に多くのものに「読む方向」を埋め込んでいるという点です。目は画面の進行方向側の端から自然に走査を始めるため、ナビゲーション、戻るボタン、進捗インジケーター、UI要素同士の読み順は、デフォルトで左から右を前提に組まれています。

レイアウトの反転

RTL地域のプレイヤーは、一般にUI全体が左右反転することを期待します。左横書きレイアウトで左側にあった要素は右側に移動し、その逆も同様です。画面左上にあった戻るボタン、画面の片側に固定されたHPバー、端からスライドインするメニュー — これらはすべて空間的な意味を持っており、テキストの向きと一緒に反転すべきものです。そうしないと、UIが表示している言語と噛み合わなくなります。

これはレイアウトシステムの課題であり、文字列の課題ではありません。UIフレームワークに組み込んで設計すべきもので、理想的にはマージン・整列・アイコンの向きをまとめて反転させる単一の方向フラグを持たせるべきです。出てきた画面を一つずつ手作業で反転させて対処するものではありません。

双方向テキスト(Bidi)

実際のRTLテキストは、純粋にRTLだけということはほとんどありません。数字はRTLの文中でも慣習的に左から右に書かれ、RTLテキストに埋め込まれたラテン文字の単語やブランド名、コードなども内部では左から右の並びを保ちます。一行の中で向きが混在するこの状態を双方向(bidi)テキストと呼び、正しく描画するには、行全体の向きを保ちながら、文字の連なりを区間ごとにどちらの向きで流すかを判定するbidiアルゴリズムが必要です。

bidi実装が壊れている場合にプレイヤーが目にする症状は、各文字自体は正しく描画されているのに、数字や埋め込まれたラテン語の単語が反転して見えたり、周囲のRTLの単語との位置関係がおかしくなったりする、というものです。

筆記体的な字形結合

アラビア文字は筆記体的なスクリプトです。ほとんどの文字は語頭・語中・語尾・単独のどの位置にあるかで形が変わり、隣り合う文字同士は連続した線でつながります。これは装飾上の選択ではありません。隣の文字と切り離された孤立形で表示されたアラビア文字は、読者には明らかにおかしく見えます。ラテン文字が上下逆さに表示されているのと同じくらい不自然です。

正しい字形結合はテキスト描画エンジン側の話であり、翻訳の話ではありません。使用しているフォントやテキストシェイピングのパイプラインがアラビア語の文脈依存字形結合に対応していなければ、翻訳がどれほど正確でも、切り離された孤立形の文字の羅列のように表示されてしまいます。

コミットする前に調べるべきこと

これはRTL対応が手の届かないものだという意味ではなく、言語対応をプレイヤーに約束する前に、範囲を明確にした上で正直に見積もるべきエンジニアリングタスクだということです。

• 自分たちのUIフレームワークやレイアウトシステムが反転(RTL)モードに対応しているか、既存UIのうち画面ごとの調整が必要な部分とグローバルな反転で済む部分がどれくらいあるか
• テキスト描画パイプラインが向きの混在するテキスト用のbidiアルゴリズムに対応しているか、アラビア語が対象ならアラビア語の文脈依存字形結合に対応しているか
• 使用フォントが対象スクリプトを正しい字形と結合挙動でカバーしているか
• 入力フィールドがある場合、RTLでの入力を正しく扱えるか。RTLフォームの中にラテン文字で入力されたユーザー名が混在するような、RTLとLTRが混ざった入力も含めて

まとめ

翻訳とRTLのエンジニアリングは、たまたま同じタイミングでリリースされる別々のプロジェクトです。レイアウトとテキスト描画に対応するエンジニアリングの見積もりを立てずに、RTL対応を翻訳予算の中の「もう一つの言語」として扱ってしまうことが、RTL対応が最もよく失敗する原因です。