多言語サイト運用でサーバー選び前に確認すること

多言語サイトを作るために、言語ごとに別のサーバーを契約する必要はありません。たとえば日本語をexample.jp/、英語をexample.jp/en/に置く構成なら、一つのサーバーで運用できます。WordPressの多言語機能を使う場合は、そのプラグインが動く環境と保守方法を確認します。

海外向けだから、すぐ海外サーバーへ移す必要があるわけでもありません。画像やフォントの容量、CDN、対象地域からの表示速度を見て判断します。言語ごとのURLとキャッシュの扱いは、契約前に制作側と決めておくと後の変更を減らせます。

翻訳を更新し続けられる範囲から始める

最初から多くの言語を用意すると、会社概要やサービス条件の変更を同時に反映できなくなります。問い合わせが多い地域と事業上必要な言語から始め、翻訳する人と承認する人を決めます。機械翻訳を使う場合も、重要な条件を誰が確認するかは残ります。

すべてを直訳する必要もありません。国内だけで使う採用条件や地域固有の案内は、対象言語から外す判断があります。掲載しないページには不完全な翻訳を置かず、問い合わせ先や基準となる言語を明示します。

料金や受付条件など変更が重要なページを先に翻訳すると、原文と翻訳の食い違いを減らしやすくなります。

Googleの多言語サイトの案内では、言語別ページに異なるURLを使う方法を勧めています。ブラウザー設定やCookieだけで同じURLの内容を切り替えると、検索エンジンや共有相手が別の言語へ到達できないことがあります。サブディレクトリなど一貫した規則を決めます。

自動転送も便利ですが、利用者が別の言語へ移れる選択肢を残します。日本にいる英語話者や海外にいる日本語話者もいます。URLを直接開けば同じ言語が表示され、言語切替後のページにも対応先があるかを確認します。

HTMLのlang属性は、そのページや文章の言語を示します。ページの基本言語をhtml要素へ設定し、途中だけ別言語になる部分にも必要に応じて指定します。右から左へ書く言語では、文字方向の指定も表示確認に含めます。

hreflangは、検索エンジンへ言語や地域の代替ページを伝える仕組みです。各ページから自分自身と対応する全ページを相互に示し、完全なURLを使います。HTML・HTTPヘッダー・サイトマップの全部へ重ねる必要はありません。保守できる一方式を選びます。

同じURLでCookieに応じて言語を変える場合、キャッシュがそのCookieを区別していないと、別の言語を返すことがあります。言語ごとにURLを分ければ整理しやすくなりますが、ヘッダーや地域判定を使う構成ではキャッシュキーの確認が必要です。更新後に古い翻訳だけ残らないかも試します。

海外からの表示速度は、サーバー所在地だけで決まりません。画像とフォントの容量を抑え、必要ならCDNで静的ファイルを近くから配信します。対象地域からトップページ・主要ページ・フォーム完了までを測ります。国内での一回だけでは判断しません。

フォームを翻訳しても、受付メールや担当部署が日本語だけでは対応が止まります。対応できる言語や返信の目安も示すと、利用者が問い合わせやすくなります。氏名や住所の入力順が地域で異なるため、日本語フォームをそのまま置き換えず実際に送信します。

アクセント付き文字や長い氏名が途中で切れないかも確かめます。自動返信には受付言語と問い合わせ番号を残し、社内で引き継げるようにします。

プライバシーや取引条件は、表示言語ごとに内容を確認します。海外向けの個別法令へ適合するかは専門家の判断が必要です。サーバーが海外から見えることと、対象地域で事業要件を満たすことは別の問題として扱います。

日本語の料金や利用条件だけが更新されると、古い翻訳を読んだ人との間で認識が食い違います。翻訳待ちの日付を管理し、重要な変更は公開停止や注意書きで伝えます。原文・翻訳・承認の状態をページ単位で追える編集環境を選びます。

言語が増えるとページや画像の容量は増えますが、単純にサーバー契約数を増やす必要はありません。通常は一つの構成で始め、対象地域の速度や運用上の分離が必要になったときに、CDNや別配信先を検討できます。