ウェブサイトのヒンディー語翻訳：デーヴァナーガリー文字・Hinglish・戦略

ヒンディー語のウェブサイト戦略：デーヴァナーガリー文字の表示、Hinglishを使う範囲、二言語対応の選択肢、ヒンディー語（hi）のSEO。

Grant Davies更新日

ウェブサイトのヒンディー語翻訳：白いグリッド上で、デーヴァナーガリー文字の音節タイルをつなぐ見出しバーと /hi チップ

要件に「ウェブサイトをヒンディー語に翻訳する」とあっても、すべてをデーヴァナーガリー文字に置き換える作業だと決めつけてはいけません。ヒンディー語へのウェブサイトのローカライズでは、市場の実情を踏まえる必要があります。インドには英語のUIを抵抗なく使うユーザーが多い一方、ヒンディー語だからこそ得られる信頼や、英語だけでは届かない層へのリーチもあります。重要なのは、どこでヒンディー語を使い、どこで二言語を併用し、どこでHinglishの使用を広告だけにとどめるかを見極めることです。

この記事は、ウェブサイトのヒンディー語（hi）版を公開するためのガイドです。戦略の選択、デーヴァナーガリー文字の表示、フォーマルな文体と日常的な文体の使い分け、クロール可能なURL、購入手続きの品質保証、MTPEと人によるレビューの比較、SEOの落とし穴（文字体系と翻字の違い）、そして実際に使えるチェックリストを紹介します。

ウェブサイトのヒンディー語翻訳では、文字列の置き換え以外に何が必要ですか？

CMSの各項目を翻訳するだけでは不十分です。明確なプロダクト戦略（ヒンディー語中心のUI、英語のプロダクト＋ヒンディー語のマーケティング、または意図的な二言語併用UI）、ボタンや幅の狭いカードでもデーヴァナーガリー文字の結合文字を正しく表示できるフォントとCSS、請求まわりの表現を明確に保つHinglishの使用方針、文体の選択（教科書的でフォーマルな表現か日常的なヒンディー語か）、そして質の高いページで対応できるヒンディー語表記の検索クエリに向けた計画が必要です。翻訳が優れていても、フォントが欠けていれば、ローカライズに不具合があると受け取られます。

このガイドでわかること

  • ウェブサイトのヒンディー語翻訳では、文字列の置き換え以外に何が必要ですか？
  • ヒンディー語のロケールや地域別バリエーションは、どれを選ぶべきですか？
  • ヒンディー語特有の文字・組版・レイアウトの課題には何がありますか？
  • ヒンディー語版サイトのURL、hreflang、インデックス登録はどう設計すべきですか？
  • ヒンディー語のオンボーディングや購入手続きでは、どのような点に注意すべきですか？
  • ヒンディー語にはAI翻訳、MTPE、人によるレビューのどれを使うべきですか？
  • ヒンディー語ページで特に避けるべきSEOのミスは何ですか？
  • ヒンディー語版サイトを公開し、成果を測定するにはどうすればよいですか？

要点：ウェブサイトを適切にヒンディー語へ翻訳するには

長く運用できるヒンディー語版を立ち上げるには、次の点が重要です。

  1. 既定のやり方に従うのではなく、戦略を選びましょう。ヒンディー語中心のプロダクトUI、英語のプロダクト＋クロール可能なヒンディー語のマーケティングページ、意図的な二言語併用UIは、それぞれ異なる仕組みです。
  2. ヒンディー語検索からの流入を狙うなら、hi（多くの場合はhi-IN）を独立したクロール可能なURLで公開しましょう。Cookieだけに依存した言語切り替えや、英語テンプレートの下に機械翻訳の段落を継ぎ足す方法では不十分です。
  3. ナビゲーション、カード、購入手続き、メールの試作には、実際のデーヴァナーガリー文字の文章を使いましょう。ラテン文字を前提にしたテーマでは、結合文字、行の高さ、ボタンの余白に問題が生じます。
  4. ブランドに合うなら、Hinglishはキャンペーンで活用しましょう。ただし、請求、権限、法務関連の文章は、より明確なヒンディー語または英語に統一します。成り行きではなく、方針として決めてください。
  5. ヒンディー語の文字表記、翻字表記、またはその両方のうち、どの検索に対応できるかを決めましょう。対応できない検索向けに、自動生成した内容の薄いヒンディー語の誘導ページを公開してはいけません。
  6. 規模を拡大する前に、相互参照するhreflang、同じ言語のURLを指定するcanonical、サイトマップを設定しましょう。
  7. プロダクト内で使う名詞は、意図的に残す英語のUI用語も含めて用語集にまとめましょう。MTPEで文体が変わったり、消費者向け画面に教科書的なヒンディー語が持ち込まれたりするのを防げます。

CSA Researchが29か国の消費者8,709人を対象に行った調査では、76%が母語の情報を見て購入することを好み、40%は他の言語のウェブサイトでは決して購入しないと回答しています。英語も読めるユーザーが多いインドでも、この傾向は当てはまります。購入手続き、請求書、サポートを、ユーザーが信頼できる言語で提供することは、やはり重要です。Googleの有用なコンテンツに関するガイダンスは、ユーザーを第一に考えたページを重視しています。本文が英語のままでナビゲーションだけがヒンディー語では、ローカライズとして不十分です。市場と言語、それぞれを軸にした戦略については、国際SEOと多言語SEOの違いをご覧ください。

適切なヒンディー語ロケールを選ぶ

ヒンディー語検索での発見を目指すなら、ほとんどのチームにとって、インド向けのhi-IN URLでhiを公開するのが適切です。初回リリースとして妥当な選択です。ただし、教科書的でフォーマルなヒンディー語、広告向けのHinglish、翻訳されずに残った英語の法務テンプレートを1つのファイルに混在させて「ヒンディー語ロケール」と呼んでよいわけではありません。

現実的な戦略は次の3つです。

  1. ヒンディー語中心のプロダクト — 幅広い消費者層向けの操作フローに、デーヴァナーガリー文字のUIを採用します。
  2. 英語のプロダクト＋ヒンディー語のマーケティング — SaaSでよく見られる形です。ヒンディー語検索からの流入を狙うなら、この場合もクロール可能なヒンディー語ページが必要です。
  3. 意図的な二言語併用UI — 運用の負担は大きくなります。どの文字列を英語のまま残すか、設計ルールが必要です。

Hinglishはキャンペーンでは効果的ですが、請求や権限の画面では雑な印象を与えがちです。使い分けの線引きを要件に明記しましょう。

ヒンディー語には文体の違いや地域ごとの特色があります。それでも、初日から1つのhiメッセージファイルで管理する設計は可能です。ただし、サンスクリット語の影響が強い文学的な文体にすれば、消費者向けの購入手続きで自然とコンバージョンが高まると考えてはいけません。通常は、日常的でわかりやすい表現のほうが成果につながります。ネイティブの編集者に文体のバランスを調整してもらいましょう。

氏名と住所の扱いも決めておきましょう。デーヴァナーガリー文字を受け付けないフォームや、氏名をASCII文字だけで入力させるフォームでは、表示上の文字列が「翻訳済み」になっていても、利用時に問題が生じます。UIを英語のままにする場合も、支払い前にユーザーが確認する、信頼に関わるページはローカライズしてください。

ヒンディー語の文字・組版・レイアウトで注意すべき点

ウェブでのヒンディー語対応は、デーヴァナーガリー文字を正しく表示するための取り組みです。結合文字、母音記号（マートラー）、行の高さについて、フォントの品質確認が必要です。ラテン文字を前提としたCSSでは、ボタン内の文字が切れたり、モバイルナビゲーションで不自然に改行されたりします。ヒンディー語を「英語より少し背の高い文字」として扱ってしまうためです。モバイルナビゲーションや幅の狭いカードでは、実際のヒンディー語を使ってテストしましょう。

公開直後に不具合のスクリーンショットが出回らないためのレイアウトルール：

  • 主要画面の試作には、デーヴァナーガリー文字風のダミーテキストではなく、実際のヒンディー語の文章を使いましょう。
  • 結合文字の上下に十分なスペースを確保できるよう、ラテン文字向けテーマよりも行の高さを大きくしましょう。
  • ボタンの内側の余白を広げましょう。英語のCTAと同じように1行に収めるために、文字を小さくしてはいけません。
  • UI、メール、PDFでは、デーヴァナーガリー文字に対応したフォントを本番環境に用意しましょう。文字化けの四角い記号が出るよりは、システムのヒンディー語対応フォントにフォールバックするほうが適切です。気づかないままラテン文字用フォントにフォールバックするのは、品質上の問題です。
  • カードのタイトル、バッジ、表の見出しに注意しましょう。文字の切れは、こうした場所で最初に現れます。
  • 二言語併用UIでよく見られる英語とヒンディー語の混在文字列が、同じ行の高さの中で重ならずに表示されることを確認しましょう。

日付や数値もレイアウト設計の一部です。文章中の日付は日・月・年の順にし、インドで販売する場合は通貨にINR、郵便番号にはZIPではなくPINコードを使います。消費者向けの価格表示にlakh（10万）やcrore（1,000万）を使うかどうかも明確に決めましょう。ヒンディー語のリストを英語のASCII順に並べるだけでは、適切な照合・並べ替え方針とはいえません。

文章のリズムも重要です。フォーマルなヒンディー語か、日常的なヒンディー語かによって、操作説明の印象は変わります。消費者向けプロダクトには、通常、日常的でわかりやすい表現が適しています。機械翻訳でよく起きるのが、過度に堅い表現になることです。「正しく」見えても、教科書のように感じられます。エラーメッセージでは、実際に人々が使う言葉で解決方法を示しましょう。

1つのボタンに英語とヒンディー語を混在させる場合は、幅に余裕を持たせ、意図的にスタイルを設計する必要があります。既定の英語フォントを使い、単語の途中でヒンディー語フォントにフォールバックさせる方法では不十分です。

クロール可能なURL、hreflang、インデックス登録

Googleは、Cookieやブラウザの言語設定だけに頼るのではなく、言語版・地域版ごとに異なるクロール可能なURLを用意することを推奨しています。Googleは主に表示されるコンテンツからページの言語を判断するため、本文が英語のままでナビゲーションだけが翻訳されていても、十分なヒンディー語版とはいえません。ヒンディー語専用のフォルダまたはホストのパターン（/hi/、/hi-in/）を用意し、テンプレート、アクセス解析、内部リンクの全体で一貫して使いましょう。

UIは英語のままでも、ヒンディー語検索で見つけてもらいたいなら、クロール可能なURLで実質的な内容のあるヒンディー語のランディングページとヘルプページを公開しましょう。英語テンプレートの下に機械翻訳の段落を継ぎ足すだけでは不十分です。ヒンディー語UIを提供する場合は、英語を好むユーザーが言語選択から英語版を利用できるようにし、自動リダイレクトで意図しない言語に固定されないようにしましょう。

hreflangの指定は、宣言した代替ページの集合内で相互に参照する必要があります。各ロケールのURLには明確なcanonicalを設定し、重複ページがある場合は同じ言語の優先URLを正規URLとして指定しましょう。ヒンディー語ページのcanonicalに、対応する英語ページを指定してはいけません。

Bing Webmaster Guidelinesでは、市場を問わず、クロール可能で役立つコンテンツと明確なサイト構造が重視されています。共通の基盤を構築したうえで、GoogleとBingの両方を対象にする場合は、Google Search ConsoleとBing Webmaster Toolsで状況を監視しましょう。Googleは、推測した言語や所在地に基づいてユーザーを自動的にリダイレクトしないよう勧めています。代わりに、ヒンディー語のURLへリンクする、見つけやすい言語選択を用意してください。IPアドレスから「インド → /hi」と判断する仕組みは、旅行者、VPN利用者、英語を好むユーザー、クローラーを不適切な誘導に巻き込みます。

URLの方針とページ内の表記方針は、同じである必要はありません。運用上の理由でスラッグにASCII文字を使うことはできますが、タイトル、H1、本文には、対応をうたっている文字体系を使うべきです。デーヴァナーガリー文字のページだけをインデックス登録するなら、翻字表記にも対応していると約束してはいけません。ヒンディー語の文字による検索も、翻字による検索も存在します。質の高いページで現実的にどちらに対応できるかを決めましょう。自動生成した内容の薄いヒンディー語の誘導ページは、誰の役にも立ちません。

インデックス登録されるH1が教科書的なヒンディー語だと、実際の検索表現とかみ合わないことがあります。文体は後から考えるのではなく、要件の段階で決めましょう。

対象言語でのオンボーディング、信頼構築、購入手続き

より幅広いユーザー層に購入を促すときは、機能一覧の翻訳よりも、信頼につながるヒンディー語ページのほうが大きな役割を果たします。多くのインドのユーザーは英語でSaaSへの登録を完了できますが、信頼できない言語では購入手続きやサポートを最後まで利用しないユーザーも少なくありません。アプリの基本UIを英語のままにする場合でも、プライバシー、利用規約、支払いに関する文章は、ローカライズの重要項目として扱いましょう。

ヒンディー語版のコンバージョンにつながる実践的なチェック項目：

  • ヒンディー語優先、英語＋ヒンディー語でのマーケティング、または二言語運用のルールという方針が明確で、ページごとに場当たり的に混在させていない。
  • ホームページ、広告、製品UIで、ヒングリッシュ（ヒンディー語と英語の混用）を使う範囲が守られている。広告では混用できても、請求書では通常避けるべき。
  • フォームでデーヴァナーガリー文字の氏名や住所を入力できるか、ラテン文字での入力が必要な理由が説明されている。
  • Cookieと同意に関する文言を、実際のバナー上で確認している。デーヴァナーガリー文字は英語とは改行のされ方が異なる。
  • 価格表示、請求書、通貨に関する表記が、対象として掲げる市場に合っている。
  • サポートの定型文とトランザクションメールでデーヴァナーガリー文字が正しく表示される。「無難なASCII文字だけ」のメールテンプレートが残っているなら、ローカライズの抜け漏れとなる。
  • エラーメッセージには、形だけの堅苦しい謝罪ではなく、日常的なヒンディー語、または意図的に残した英語を使っている。
  • モバイルでの入力：ユーザーはヒンディー語の文字でもローマ字表記でも検索する可能性がある。両方に対応するなら両方をQAで確認する。ただし、維持できない表記のために内容の薄いページを公開しない。

対応をうたう言語では、ホームページと製品説明に加え、認証、料金、購入手続き・請求、プライバシーに関する基本情報、サポート窓口、法的情報のページを用意する必要があります。

フランス語のAI翻訳、MTPE、人によるレビュー

ヒンディー語にはAI翻訳、MTPE、人によるレビューのどれを使うべきでしょうか。ツールのブランドではなく、リスクに応じてワークフローを選びましょう。

  • 未編集の機械翻訳：使えるのは社内向けの下書きまでです。モデルは教科書的で堅いヒンディー語を生成したり、不適切な箇所でヒングリッシュを多用したり、デーヴァナーガリー文字のレイアウトを考慮しなかったりします。
  • MTPE（機械翻訳＋ポストエディット）：用語集で製品関連の名詞と意図的に残す英語の用語を固定できていれば、多くの製品ページやサポートページで有力な基本の選択肢になります。
  • 人による翻訳／ブランド表現の編集：ホームページ、料金、キャンペーン、Cookie・同意、法務に関わるページ、そして意図して設計された見せ方が必要なあらゆる二言語表記に適しています。

ヒンディー語の実践的なレビューサイクル：

  1. 方針と用語集：どの文言を英語のままにし、どれをヒンディー語にするか、どこでヒングリッシュを認めるかを決める。
  2. その用語集と文体（日常的か、改まった表現か）に沿ってMTPEの原稿を作成する。
  3. ブランド担当の編集者がホームページ、料金ページ、主要なランディングページを確認する。
  4. 操作説明とエラーメッセージが教科書調にならないよう、ネイティブの編集者がチェックする。
  5. ステージング環境でモバイルの画面幅に合わせてQAを行い、メール、PDF、ボタン内の文字切れも確認する。

ユーザーを第一に考えた有用なコンテンツという要件は、どの言語にも当てはまります。機械翻訳だけで作った低品質なヒンディー語ページは、CMS上では完成しているように見えても、ユーザーのニーズや検索品質の基準を満たしていないことがあります。

ヒンディー語特有のSEOの落とし穴

ヒンディー語で検索するユーザーは、自分が入力した文字体系で書かれた自分が読める言語を求めています。英語の主要キーワードを逐語訳したり、デーヴァナーガリー文字のページしかないのにローマ字表記のタイトルで上位表示を狙ったり（またはその逆）しても、実際の検索行動には合いません。対応する表記に合わせてヒンディー語のキーワード調査を行い、その検索クエリに合うタイトルとH1を作成しましょう。

ヒンディー語のURLごとに、タイトル、メタディスクリプション、見出しをローカライズしましょう。英語のメタデータ一式を複数のロケールで使い回さないでください。

特にヒンディー語ページに悪影響を与えるミス：

  1. 有用なコンテンツの要件を満たさない、自動生成された内容の薄いヒンディー語の誘導ページ。
  2. 共通部分だけの翻訳。ナビゲーションなどのUIはヒンディー語でも、本文は英語のまま。
  3. デーヴァナーガリー文字のフォントの欠落により、インデックス登録されたページの表示が崩れる。
  4. 広告では自然なヒンディー語で使える製品をうたっているのに、請求関連ではヒングリッシュを使う。または、意図せずその逆になっている。
  5. Cookieだけに依存した言語切り替えにより、クローラーがヒンディー語のURLを見つけられない。
  6. 不備のあるhreflang（相互参照リンクの欠落）。
  7. 地域に基づく自動リダイレクトにより、英語を希望するユーザーやボットが意図しない言語に固定される。
  8. 維持できないローマ字表記のページが、canonicalの運用方針もないままデーヴァナーガリー文字のURLと競合する。
  9. 日常的な検索表現と合わない教科書調のタイトル。

コンテンツの量を増やす前に、方針、フォント、サイト構造を整えましょう。

公開前のチェックリスト

ヒンディー語版を公開する準備ができたら、このチェックリストで確認しましょう。

GlotEOが担う役割

ヒンディー語は、明確な管理ルールのもとで運用するのに適したロケールです。デーヴァナーガリー文字のコンテンツを更新しても製品関連の名詞を統一し、英語のまま残すUI用語にも表記のぶれが生じないようにする必要があります。ウェブサイトのローカライズプラットフォームの用語集と翻訳メモリを使えば、文体、二言語運用のルール、機能名の一貫性を保ちながら、レイアウト確認済みのテキストを公開できます。さらに多言語SEOツールを組み合わせれば、展開を広げてもヒンディー語のURL、hreflang、メタデータを確認しやすい状態に保てます。最初のhiリリースの範囲を決める際は、GlotEOの料金とプランを比較してください。まだ対応言語を選んでいる段階なら、より包括的なウェブサイト翻訳のワークフローから検討を始めましょう。

JSON辞書や機械翻訳であることが明示されていない下訳では、hiを安心して公開できなくなったら、GlotEOのウェブサイトローカライズをご検討ください。

参考文献