アラビア語の旅行予約サイトは翻訳ではない

ジッダのある旅行会社がアラビア語の切り替えを有効にし、自社のトップページを眺め、これで仕事は終わったと判断する。二週間後、ある顧客が運賃のリンクをWhatsAppで妹に転送すると、届いたのはパーセント記号の壁だった。別の顧客は、合計金額が価格の間違った側に出ていると言って電話をかけてくる。三人目はNRT–DXBを一日ずれた日付で予約してしまう。日付ピッカーが週を月曜から始めていたからだ。どれも翻訳の不具合ではない。アラビア語の旅行予約サイトは、文字列の集合である前に、レイアウトであり、数字の体系であり、URLの方針である。それでも文字列が先に片づく。スクリーンショットに写るのがその部分だからだ。
実際に何が変わるのかを、旅行会社がぶつかる順に並べてみる。
RTLは文字の向きではなくレイアウトの判断だ
dir="rtl"を指定すればページは鏡のように反転する。ナビゲーションが右へ、絞り込みのレールが左へ移り、段落は右揃えになる。ここまではほぼ無料だ。高くつくのは、反転してはいけないすべてのほうである。
運航時刻は反転しない。07:45はどこでも07:45だ。NRTからDXBと読める行程のストリップは、右から左へ流れる段落の中でも、その順で経路として読めなければならない。文がどちら向きに流れようと、出発空港は出発空港だからだ。航空会社コード、PNR、eチケット番号は、アラビア語の文中に落とし込まれたラテン文字列であり、これらを分離しないとブラウザのbidirectionalアルゴリズムが周囲の約物を並べ替える。予約番号に続く句点が反対の端に出ることがあり、顧客の目には自分の予約参照番号の誤植に見える。ロゴは反転しない。再生の三角も反転しない。戻る矢印は反転する。
そしてここからが、顧客に言われるまで誰も一覧にしないものだ。通貨記号と数字の順序、予約フローを横切る進行ステッパー、座席表、カルーセルが進む向き、検索結果の行のどちら端に航空会社のロゴが座るか、横に広い運賃表がどの縁からスクロールするか。そのひとつひとつが判断である。どれも、入れれば済むフラグではない。
数字、日付、そして顧客が実際に手にしている暦
アラビア語は二種類の数字で書かれ、どちらも日常的に使われている。一方で旅行は数字だらけだ。運賃、時刻、所要時間、手荷物許容量、カード入力欄、OTPコード。自分の市場がどちらを読むのかは、自社の顧客と一度だけ答えを出し、その後は例外なく適用すべき問いである。目に見える失敗は、使用頻度の低いほうを選ぶことではない。失敗は混ぜることだ。同じ検索結果カードの上で価格が一方の数字、出発時刻がもう一方の数字になっていれば、作りかけのサイトに見える。
日付は数字よりも多くの前提を連れてくる。月曜に始まる週は、週が日曜に始まる顧客にとっては誤りであり、始まる曜日を間違えた暦はちょうど一種類の誤りを生む。一列ずれた予約だ。ウムラを計画している顧客はグレゴリオ暦ではなくヒジュラ暦の月で動いている。日付ピッカーと行程表でグレゴリオ暦の隣にヒジュラ暦の日付を出すのは、費用がかからないうえに電話を一本減らす。逆に、フランクフルト出張の画面にまでどこでも出すのは雑音でしかない。
アラビア語の予約サイトが外してはならない点
翻訳しただけのサイトと、現地化されたサイトの差は、全体ではなく画面ごとに現れる。開発者と議論する価値のある一覧はこれだ。
| 画面 | 翻訳しただけ | 本当に現地化された状態 |
|---|---|---|
| 搭乗者名 | 入力欄のラベルがアラビア語 | ラテン文字で入力させ、パスポートの表記どおりにと明示する。航空会社がPNRで保持しているのがその名前だからだ |
| 日付 | 月名がアラビア語 | 読み手の週の初日、読み手の数字、旅程が求めるときはグレゴリオ暦の隣にヒジュラ暦 |
| 金額 | 通貨名を訳す | その市場の既定通貨と、実際に販売している通貨の一覧 |
| 電話とOTP | ラベルがアラビア語 | その市場の国番号をあらかじめ選択し、入力欄はラテン数字、コードは一目で読める |
| 空港と都市 | 名称がアラビア語 | アラビア語名とともにラテン文字のIATAコードも見えている。サブエージェントはDXBと打ち、旅行者はアラビア語を読むからだ |
| URL | タイトルを訳す | 言語ごとにひとつのslug方針を、一度だけ決める |
| 書体 | システム既定のアラビア語フォールバック | 数字の形と小さい級数での可読性で選んだアラビア語書体。背後でアラビア語を借りているだけのラテン書体ではない |
| 連絡先 | 翻訳された連絡先ページ | その市場の顧客が実際にかけられる番号を、相手が起きている時間帯に |
本当に金がかかるのは名前の行であり、もっとも頻繁に間違っているのもその行だ。旅行者はフォームがそう促したからアラビア文字で名前を入力し、航空券はその文字列で発券され、航空会社が確認するパスポートと一致しない。その後に続くもの、再発行も、言い争いも、払い戻しも、航空会社ではなくあなたの側に落ちてくる。
書体の行は見た目よりも安い。このプラットフォームではフォント、色、ロゴを含むテーマを、再デプロイなしに管理画面から差し替えられる。だから別のアラビア語書体を自社の運賃表に当ててみるのは、リリースではなく半日の作業だ。通貨の行はそれ自体が別の主題で、そこは多通貨の価格設定と利益が漏れる場所で扱った。
slugと、WhatsAppに貼り付けても残るもの
アラビア語のslugはアドレスバーで美しく表示され、人が検索窓に実際に打つ語でできている。ところがプレーンテキストの欄にコピーされた瞬間にpercent-encodeされて何倍にも膨らみ、顧客が転送するものは機械の出力のように見える。ラテン文字への翻字はきれいに貼り付くが、誰にも読めない。アラビア語の読者が検索する語とも、英語の読者が検索する語とも一致しないからだ。
そのURLが何のためのものかで判断を分けよう。コンテンツページは検索で生き死にするのだから、その言語自身の文字によるslugを与える。エンコードされた形が現れるのは誰かがコピーしたときだけで、着地するページはどちらでも正しい。予約のディープリンクは、検索結果でも、押さえた運賃でも、サブエージェントへの見積もりでも、どのみち美しくならない。すでにクエリ文字列に日付と人数を載せているからだ。そちらには短いリンクを与え、短いままにしておこう。
両方の下にある規則はひとつ。言語ごと、ページごとにcanonical URLはひとつ。同じ記事をアラビア語のslugと翻字のslugの両方で公開すれば、そのページが稼ぐものは二つのアドレスに割れ、手元には維持すべきものが二つ残る。
hreflang、さもなければアラビア語のページが自社の英語ページと競う
ひとつのページの二つの言語版は、二つのページではない。クローラーがそれを見分けられないとき、もっとも多い結末は制裁ではない。一方の版が選ばれ、もう一方はほぼ重複として扱われ、静かに落とされることだ。
両者を分けるものは四つある。各言語に自分のURLが要る。この一点で、JavaScriptの切り替えによる単一アドレスは外れる。どの版も自分自身を含めてすべての言語を列挙する。自分を指し返さない集合は丸ごと捨てられるからだ。各ページのcanonicalは英語の原文ではなく自分自身を指す。アラビア語のページを英語にcanonicalで寄せるのは、アラビア語のページを一枚も索引させない最短の方法である。そしてx-defaultは、一致する言語を持たない読者に着地してほしい場所へ向ける。
通貨も電話番号も在庫も本当に違うのでない限り、ar-AEとar-SAに分けるのは控えよう。同じ原稿の地域違いが二つあるということは、同じクエリを奪い合うページが二つあるということで、しかも両方に自社の名前が載っている。
ここを外したときに払う代償
離脱はトップページでは起きない。起きるのは搭乗者情報の画面で、ファネルの中でもっとも高くつく場所だ。顧客はすでに検索し、選び、価格を見て、それに同意している。そこまで連れてきた検索の費用も、あなたはすでに払っている。
残りの代償はもっと静かだ。戸惑って電話をかけてくる一人ひとりが、オンライン化して減らすはずだったスタッフの一分である。名前の不一致のひとつひとつが再発行一件であり、航空会社ではなくあなたを責める顧客一人である。そして一度も索引されないアラビア語のページは、費用を払って書かせたのに誰にも見つけられない記事だ。苦情がまったく出ない唯一の種類の失敗であり、だからこそ一年間そのまま走り続けることがある。
どこから始めるか
アラビア語が二番目の市場なら、この仕事は後付けの改修であり、上の表がそのまま指摘事項の一覧になる。最初の市場なら順序は逆になる。配色より先に数字の体系とアラビア語の書体を決め、本物のパスポートを手元に置いて搭乗者フォームを作り、英語のほうを翻訳として扱う。
どちらにせよ、いちばん安い検証は、本物の顧客一人の前に置いた本物のストアフロントだ。旅行サイトを作るのウィザードは、そのフォームだけでプラットフォームのサブドメイン上に自社ブランドのサイトを立ち上げ、カード情報を求めない。ストアフロントはアラビア語、ペルシア語、ヘブライ語、ウルドゥー語を含む40言語で提供され、独自ドメインは後から付けられる。エンジンを自前で作るかどうかをまだ決めかねているなら、その議論はこちらに整理してある。ただし決める前に一度アラビア語でやってみてほしい。社内見積もりから抜け落ちるのは、いつもRTLの作業だからだ。