アラビア語サイト開発で右から左へのレイアウトをどのように処理するか

アラビア語サイト開発の多言語プロジェクトにおいて、「ページを左から右へミラーリングする」ことは、RTL（Right to Left、右から左）対応の完了を意味しません。実際に公開品質へ影響するのは、ページ方向、コンポーネントの動作、双方向テキスト、サードパーティツール、コンテンツ運用ルールがすべて整合しているかどうかです。direction: rtlを1行追加するだけで本文を右寄せにできる場合もありますが、メニュー階層、フォーム検証、アイコン、数値、商品仕様、広告ランディングページに予測しにくい問題が生じます。

より安全な方法は、言語単位でドキュメント方向を設定し、絶対方向のスタイルの代わりに論理プロパティを使用し、RTLをプロジェクト後期の視覚的なパッチではなく、デザインシステムとコンポーネントライブラリの正式な状態として扱うことです。これにより、今後英語、フランス語、アラビア語などのサイトを追加しても、コードの保守コストが言語数に比例して増加することはありません。

「テキストの右揃え」と「ページのRTL」をまず区別する

アラビア語は主に右から左へ記述されるため、アラビア語ページでは通常、ルートノードでlang="ar"およびdir="rtl"を宣言する必要があります。前者はブラウザ、スクリーンリーダー、検索エンジンによる言語認識を支援し、後者はテキストフロー、ブロックレベルレイアウトの開始位置、スクロール動作、一部のネイティブコントロールのデフォルト方向を決定します。

本文にtext-align: rightを追加するだけでは、段落の視覚的な配置が解決されるだけで、Flex、Grid、配置要素、フォームコントロールの論理方向は変わりません。反対に、サイト全体へ直接RTLを適用すると、電話番号、メールアドレス、注文番号、製品型番などの左から右へ読む内容が読みにくくなります。アラビア語サイト開発における多言語対応の難しさはここにあります。ページの主言語がRTLであっても、ページ内のすべての文字をRTLの規則で配置すべきとは限りません。

方向制御は、局所的なスタイルファイルではなく、言語ルーティングまたはページのルートコンテナに配置することを推奨します。たとえば、アラビア語の独立ディレクトリでは、ページのHTMLタグにdir="rtl"を設定できます。シングルページアプリケーションでは、言語切替時にdocument.documentElement.langとdocument.documentElement.dirも同期して更新する必要があります。CSSクラス名だけに依存して方向を模倣しないでください。そうすると、ブラウザのネイティブ機能とアクセシビリティの意味づけが完全には有効になりません。

レイアウトには「論理プロパティ」を使用し、leftとrightに依存しない

RTLプロジェクトで最も技術的負債が蓄積しやすいのは、大量にハードコーディングされたleft、right、margin-left、padding-rightです。これらのプロパティは物理的位置を示すため、言語切替後には通常、追加の上書きルールが必要になり、最終的にはLTRスタイル一式とRTL修正スタイル一式が併存することになります。

多言語サイトには、CSS論理プロパティがより適しています。これらは「インライン開始、インライン終了、ブロック開始、ブロック終了」によって位置を表現し、ブラウザが記述方向に応じて自動的にマッピングします。

新規プロジェクトでは、論理プロパティをコンポーネント規約の一部にすべきです。既存サイトでは必ずしもすべてのCSSを一度に書き換える必要はありませんが、ナビゲーション、フィルター、フォーム、ポップアップ、商品詳細、問い合わせモジュールなど、コンバージョン頻度の高いコンポーネントは優先的に改修すべきです。flex-direction: row-reverseを使用してレイアウトを強制的に反転する場合も注意が必要です。視覚上の順序とDOM順序が一致しなくなり、キーボードのフォーカス移動、スクリーンリーダーでの読み上げ、一部のトラッキングロジックに影響する可能性があります。

ミラーリングが必要な要素と、不要な要素

RTLは「サイト全体を水平反転する」ことではありません。ナビゲーションの閲覧順序、パンくずリストの方向、ドロワーの展開方向、カルーセルの前後切替矢印、戻る矢印など、閲覧フローに関連する要素は通常、RTLに合わせて変更すべきです。ページ上部のブランドロゴ、検索入口、メインナビゲーション、言語切替が依然としてLTR構造のままであれば、アラビア語ユーザーは操作の流れに明らかな不自然さを感じます。

ただし、ブランドロゴ、商品の実物画像、地図、国旗、再生アイコン、ソーシャルプラットフォームの公式ロゴ、および固定された意味を持つ一部の図形は、機械的にミラーリングすべきではありません。特に商品詳細ページでは、機器パネル、パッケージラベル、インターフェース位置などの画像は実際の方向を保つ必要があります。視覚的な統一だけを目的に画像を反転すると、かえって購買や使用時の判断を誤らせる可能性があります。

アイコンシステムには、「方向依存」の識別を設けるのが最適です。矢印、入る、戻る、次へなどのアイコンにはRTLバリエーションを使用するか、RTL環境で水平反転を行えます。一方、ダウンロード、閉じる、検索、電話など、方向の意味を持たないアイコンは通常そのままにします。アイコンコンテナ全体にtransform: scaleX(-1)を適用しないでください。反転すべきでない多くの図形まで誤って反転されます。

双方向テキストはフォームと商品情報における高リスク項目

アラビア語ページには、英語のブランド名、URL、メールアドレス、電話番号、金額、寸法、SKU、製品型番が混在することがよくあります。たとえば、1件の問い合わせ記録では、アラビア語の説明文とAB-1200、220V、メールアドレスが同時に表示されます。ブラウザの自動判定に依存すると、句読点、括弧、数値が視覚的にずれることがあり、コピー後の順序も表示されている順序と異なる可能性があります。

処理原則は、データの種類ごとに明確な方向を持たせることです。アラビア語の説明フィールドはRTLを継承し、メールアドレス、URL、追跡番号、コード、技術型番にはdir="ltr"を使用します。金額、日付、数量は統一されたフォーマットコンポーネントから出力すべきです。フォーム入力欄については、ラベル位置、カーソル開始位置、エラー表示、ドロップダウン、日付ピッカー、認証コードもそれぞれ確認する必要があります。ページが正常に見えても、ユーザーが問題なく入力を完了できるとは限りません。

リッチテキストコンテンツもルールの対象に含める必要があります。エディタは段落方向の切替をサポートし、コンテンツのインポート時に英語リンクや表構造を壊してはなりません。自動翻訳を使用する場合でも、翻訳後のテキストはページプレビューで確認する必要があります。翻訳文の長さ、アラビア語フォントの字形、数値の混在はいずれもモジュールの高さを変化させるためです。

多言語アーキテクチャでは「アラビア語は単なるテーマスキン」を避ける

言語、コンテンツ、方向は階層的に管理すべきです。言語ルーティングはlang、dir、ページタイトル、代替言語の関係を決定します。コンポーネントシステムはLTRとRTLで正しいレイアウトを表示し、コンテンツ管理はローカライズされた文言、画像説明、フォームフィールドを保守します。分析システムでは、異なる言語ページにおけるコンバージョンイベントの意味が一貫していることを保証する必要があります。

サイトが独立した言語URLを採用している場合は、各アラビア語ページにアクセス可能かつインデックス可能な安定したアドレスを持たせ、他言語版を正しく関連付ける必要があります。すべての言語コンテンツをフロントエンドのポップアップに詰め込み、その後で動的に置き換える方法は避けてください。検索エンジンのクロール、共有プレビュー、広告ランディングページの再利用はいずれも制御が難しくなります。問い合わせや越境ECを目的とするサイトでは、通貨、税金の説明、配送エリア、プライバシー通知、カスタマーサービスへの入口がターゲット市場の言語と一致しているかも確認すべきです。RTLはローカライズ体験の一部にすぎません。

易営宝のように多言語サイト構築、SEO、海外プロモーションをカバーするシステムを例にすると、選定時にはアラビア語言語パックの提供有無だけを見るべきではありません。テンプレート、ナビゲーション、フォーム、EC決済ページ、ランディングページのコンポーネントが、言語に基づいて自動的に方向を切り替えられるか、また運用担当者がRTLページを独自に保守できるかをさらに確認する必要があります。マーケティングページを1つ追加するたびに開発者がCSSを手動修正しなければならないなら、プラットフォーム機能がどれほど充実していても、継続的な広告出稿とコンテンツ更新を支えることは困難です。

公開前は実際のタスクに基づいて検収する

RTLの検収は、トップページのスクリーンショットを1枚撮るだけでは不十分です。アラビア語環境へ切り替え、ナビゲーションの閲覧、製品検索、リストの絞り込み、問い合わせの入力、注文または予約の送信、メール通知の確認、モバイル端末で前の画面へ戻るなど、一連のタスクをそれぞれ完了してください。モバイルドロワー、固定ボタン、横方向カルーセル、フローティングカスタマーサービスは方向の競合が起きやすいため、デスクトップとモバイルの両方でテストが必要です。

• ルートノードで正しい言語属性と方向属性が同時に宣言されているか確認する。
• ナビゲーション、パンくずリスト、ページネーション、カルーセル、サイドバー、ポップアップの開く方向が閲覧習慣に合っているか確認する。
• 電話番号、メールアドレス、URL、金額、日付、SKU、寸法、括弧が混在する場合の表示とコピー結果を確認する。
• キーボードのTabフォーカス順序、スクリーンリーダーの意味づけ、エラー表示が、視覚上の順序と引き続き一致しているか確認する。
• サードパーティのチャット、決済、地図、Cookieポップアップ、フォーム、広告トラッキングスクリプトのRTL表示を確認する。
• アラビア語フォント読み込み後の改行、ボタンの高さ、表のオーバーフロー、モバイル端末での横スクロールを確認する。

最終的に確認すべきなのは、「ページが右方向に配置されているか」ではなく、アラビア語ユーザーが慣れ親しんだ閲覧・操作方法で目的のアクションを完了できるかどうかです。RTLをコンポーネント設計、コンテンツ規約、検収プロセスに組み込むことで、多言語サイトはページ追加、広告出稿、機能改善の際にも保守性を維持でき、局所的な修正に継続して依存することを避けられます。