日本語からヒンディー語へ｜ウェブ・アプリ・案内文の翻訳と表示確認

日本語のサイトや案内文をヒンディー語にする際は、訳文を作ることと、利用者がその画面で目的の操作をできることを一緒に考える必要があります。正しい文章でも、文字が欠ける、ボタンの説明と実際の動作が違う、入力例が合わないといった問題があれば、案内として十分に機能しません。

インド向けだからという理由だけで読者の言語を決めず、対象地域、利用者、読み書きの環境を確認してください。ここでは日本語からヒンディー語への翻訳を、ウェブサイト、アプリ、製品案内の公開まで進めるときの確認点を整理します。

対象読者と使う場面を先に決める

ヒンディー語版を誰が読むのか、どの端末で利用するのか、何を理解・操作してほしいのかを明確にします。一般向けのサービス案内と、専門職向けの技術資料では、同じ概念でも説明の量や用語の選び方が変わります。英語の用語を日常的に使う読者なのか、ヒンディー語だけで説明を完結させる必要があるのかも確認します。

仕様書には、対象画面、用途、文体、専門用語、変更してはいけない名称をまとめます。「申込み」「支払い」「予約確定」などの操作が別なら、訳文もその違いを維持します。日本語側でこれらが曖昧な場合は、先に画面の動作を確認して原稿を整える方が、翻訳後の修正を減らせます。

文の短さだけを優先しないことも大切です。例えば「送信」とだけ表示するボタンなら、送信されるものが問い合わせなのか、注文なのかを画面の前後で理解できるか確認します。ボタンだけを一覧にした原稿には、該当画面や動作の説明を添えてください。

日本語の省略を解消してから訳す

日本語の短い案内には、誰が実施するか、誰に対する注意かが省略されることがあります。「確認後にご連絡」と書かれている場合、利用者が確認して連絡するのか、運営側が確認後に連絡するのかを確定してから訳します。読み手が誤解しないよう補う場合も、原稿にない対応期限や約束を加えないでください。

また、「できます」「してください」「必要です」は異なる役割の表現です。機能の説明、操作の指示、条件の提示を区別し、同じ調子の文章にまとめないようにします。例外や否定を短縮すると、利用条件の意味を変えてしまうため、注意書きと本文の関係まで照合します。

翻訳者に質問を返してもらう工程を確保し、未回答の箇所は暫定訳と照会をセットで管理します。画面実装後に判断が変わった場合も、元の日本語と他言語版を同時に修正できるよう、各文に対応番号を付けると便利です。

専門用語と英語表記の扱いをそろえる

ヒンディー語の技術用語を検討する参考として、インド教育省の科学技術用語委員会CSTTが公開するヒンディー語の用語集分類があります。分野別の用語や定義を調べる出発点になりますが、公的な用語を採用すればすべての読者に分かりやすい、という意味ではありません。

利用者に定着した英語名称を併記するか、ヒンディー語で短く説明するかを、媒体と読者に合わせて決めます。製品名、型番、メニュー名、サービス名は、正式表記と検索しやすさを考慮して扱います。同じ機能を画面ごとに違う名称で呼ばないことが重要です。

用語集には、日本語、採用したヒンディー語、必要な英語併記、意味、使用する画面を記録します。却下した候補と理由も残しておくと、複数人で更新する際に同じ議論を繰り返さずに済みます。自社独自の機能は外部辞書だけで定義せず、担当者の説明で確定してください。

デーヴァナーガリー文字は結合と表示を確認する

ヒンディー語で用いるデーヴァナーガリー文字では、子音と母音記号、子音同士の結合などが表示に関わります。W3Cのデーヴァナーガリー文字資料（草案）は、左から右への横書き、母音記号、文字の形や配置といった項目を整理しています。草案であり、特定環境の表示を保証する文書ではありません。

Microsoftのフォント開発資料も、文字の並びから実際に表示する字形への処理や配置を説明しています。翻訳テキストを貼り付けたあとには、使用するフォントと閲覧環境で結合文字や記号が正しく表示されるかを確認してください。文字間隔を広げる装飾や無理な改行で、語のまとまりを損なわないようにします。

見た目を固定するためにすべての本文を画像にすると、後からの修正や検索が難しくなります。可能な範囲で文字データを保持し、画像内に含まれる文字は別に管理します。印刷物なら、編集用データと出力PDFを両方確認し、フォントの置換で配置が崩れていないかを点検します。

AI翻訳の結果は画面の中で見直す

DeepLの対応言語案内にはヒンディー語が含まれています。ただし、対応言語の掲載と、用語集、文体指定、ファイル翻訳などの機能をすべて同じ条件で使えることは別です。必要な機能と利用環境を確認し、実際に扱う文章で試してから工程に組み込みます。

短い画面文言を個別に訳す場合は、文脈が不足しがちです。画面名、利用者の操作、前後の表示を合わせて確認します。下訳を採用する際にも、日本語の条件、数量、否定、期限と一致するかを対照し、文字が自然に見えるという理由だけで完了としないでください。

機密の仕様や個人情報を扱う場合は、組織が認めた利用環境とデータの取り扱い条件を確認します。無料・有料という区分だけで、用途への適否や品質を判断しないことが重要です。

公開前の確認は操作と表示をセットで行う

スマートフォンとPCで主要な画面を開き、申込みや問い合わせの流れを確認します。閲覧だけでなく、長い氏名を入力した場合や、未入力の項目がある場合など、表示が変わる箇所も対象にします。これらは実際の製品の仕様に基づいて試す必要があります。

納品時には、承認済み訳文、用語集、表示確認の対象環境、未解決の項目をそろえます。日本語版の改訂で再確認が必要になる文を追跡できるようにしておけば、ヒンディー語版を公開後も維持しやすくなります。