WordPressを日本語・英語で公開するには？ページとメニューの切り替えをそろえる方法

言語設定と翻訳を分け、更新できる方式を選ぶ

WordPressで使う「言語」は一つの仕事を指す言葉ではありません。編集する人の管理画面、訪問者が読む本文、サイト内を移動するメニュー、別言語へ移るリンクを分けて考えます。管理画面が英語になっても、日本語で書いた製品説明や資料請求ページが英訳されたことにはなりません。

また、閲覧者がブラウザーでその場だけ訳して読むことと、会社が内容を確認した英語版を継続して公開することも別です。外国語の他社サイトを読む方法は、本文・画像・音声を分けて翻訳する記事で扱っています。自社の英語版では、誰が訳文を確認し、日本語版の変更をどう反映するかまで必要です。

方式を選ぶ前に、まず対象を決めます。製品紹介もお知らせも一度に英語化するのか、資料請求など必要なページから始めるのか。誰が文章を更新し、誰が英語を確認するのか。問い合わせに対応できる言語と窓口はどこか。この条件をそろえると、機能名だけで選ぶより、継続できる方式を判断しやすくなります。

たとえば言語別のページを関連づける方式なら、対応ページを確認しながら更新する仕事が発生します。言語ごとにサイトを分ける方式なら、それぞれの運用や保守の負担も確認します。自動翻訳を表示する方式でも、会社が公開する説明として誰が内容と条件を確かめるかは残ります。どの方式でも、現在のテーマ・追加機能・編集方法との適合を確認してください。

すでに多言語用の機能がある会社では、別の機能を追加する前に、現在の方式と対象ページの管理方法を制作・保守担当へ確認します。新しく導入するなら、現在の説明書と利用条件を読み、バックアップと復元方法を確かめ、許可された試験環境で必要なページとメニューの動作を見ます。本番サイトへ思いつきで追加したり、既存機能を無効にしたりする手順ではありません。

WordPress公式の一般設定では、Site Languageは管理画面の言語として説明されています。公式の多言語サイトの説明は、言語別ページの関連づけ、URLによる言語の区別、導入前の試験などを扱っています。掲載されている古い製品例や個別操作を、現在の全環境に共通する手順としては使いません。

同じ目的の日本語・英語ページを組にする

言語切替は、「英語のどこかへ移ればよい」という案内ではありません。日本語の資料請求ページから切り替えるなら、英語でも同じ資料請求の目的を続けられるページを対応先として決めます。会社の英語トップページへ移す場合は、対応ページへの切替とは違う案内になることを明確にします。

下の架空例では、日本語の資料請求ページを/ja/request/、英語版を/en/request/としています。どちらも説明用の文字列で、このサイト上のリンクではありません。このURL構造がすべてのWordPressで自動生成されるという意味でもありません。現在の方式に従って、実際に使うURLを確認してください。

編集担当は、現在の多言語機能の説明に沿って、それぞれのページへ言語を指定し、対となるページを関連づけます。ページ名が似ているだけで選ばず、資料の内容、利用目的、案内する条件を読み合わせます。日本語版を複製した場合も、英語の本文・画像内の文字・ボタン・注意書きまで確認する前に、英語版が完成したとは扱いません。

URLは、言語の判別と更新管理の両方に関係します。Googleは言語別に異なるURLを使う方法を案内していますが、ディレクトリ、サブドメインなどから自社の方式を選ぶ仕事と、ページの中身を英語にする仕事は別です。既存URLを変える場合の移行も、この例のURLをコピーするだけでは決まりません。

英語へ切り替えれば、案内も全部そろう？

図では、日本語・英語の資料請求ページの対応と、それぞれのメニュー、英語の問い合わせ先を分けて見てください。ページ対とメニュー名は架空の設定です。実際の切替、問い合わせ先への到達、訳文の確認はまだ分かっていません。英語版未準備のお知らせは、資料請求ページを修正した後ではなく、別条件の例です。

説明図の原画を開く

この例では、英語版への対応先が書かれていても、英語の問い合わせ先が未確認です。公開判断に進む前に、担当がその行き先と案内内容を確かめます。図のページ間の線は対応づける関係を表し、切替の試験成功や資料請求の受付実績を表しません。

言語別URLと利用者が自分で選べる切替リンクについては、Google検索セントラルの多言語サイトの説明を参照しています。検索向けに言語版の関係を伝えるhreflangと、利用者が操作するリンクは役割が違います。どちらかを設定しただけで、翻訳・リンク到達・検索掲載や順位が保証されるわけではありません。

メニューの文字と、実際のリンク先をそろえる

英語の本文を用意しても、上部メニューが日本語の製品ページや資料請求へ戻るままなら、訪問者は英語だけで目的を続けられません。まず英語ページに表示されるメニューを開き、項目の文字とリンク先を一つずつ確かめます。「Request information」と表示されていることと、対応する英語ページへ到達できることは別に確認してください。

編集する場所はテーマなどで異なります。ブロックテーマでは、サイトエディターのナビゲーションブロックなどで扱います。従来型のテーマなどでは、「外観」の「メニュー」が使える場合があります。画面が見つからないときに、別テーマへ変えたり追加機能を停止したりする必要はありません。現在のテーマで対象ページが使うメニューと、その編集場所を管理担当へ確かめます。

ナビゲーションブロックでは、まず選択中のメニューが日本語用か英語用かを確認します。対象の項目を選び、表示する文字とリンク先を読みます。ページを追加する場合も、目的の言語版かを本文とURLで確かめて選びます。別メニューへの切替や新規メニューの作成は、現在の構成と多言語機能の対応が分かってから行ってください。

「外観」の「メニュー」を使う構成なら、編集対象のメニューを選び、項目に入っているページと表示する名前を確認し、表示位置も照合します。英語という名前のメニューを作っただけでは、英語ページに表示されるとは限りません。どの言語でどの位置に出すかは、現在のテーマと多言語機能の方法に合わせます。

確認範囲には、上部だけでなくフッターやスマートフォンで開くメニューも含めます。複数ページが同じ共通部分を使うなら、一か所の変更がどのページへ及ぶかを確認します。保存前に変更対象を見直し、保存後は編集画面だけで終えず、対象言語の読者向けページで実表示を確かめます。

問い合わせ先も、その言語で利用できる行き先かを見る

問い合わせボタンは、文字だけ英語にして終わりにしません。リンク先の説明、入力欄の案内、送信前の注意、受付後の案内、窓口が対応できる言語を担当者と確認します。英語の受付を用意できない場合は、対応条件を明記するのか、別の確認済み窓口を案内するのかを決めてから掲載します。

架空例では、英語の問い合わせ先と実到達結果はどちらも未確認です。資料請求ページのURLを、そのまま問い合わせ先の値として補いません。リンクを開いて案内を読む確認と、入力・送信・実受付の試験も分けます。実送信が必要なら、別途認められた試験情報・宛先・確認方法を用意してください。

公式のナビゲーションブロックは、選択するメニュー、項目の文字とリンク、スマートフォンでの表示などを説明しています。公式のメニュー画面は、従来型などの構成と表示位置を扱います。言語別の自動割当や特定プラグインとの適合まで、この説明だけで保証するものではありません。

英語版が未準備なら、切替先を決めるまで保留する

日本語のお知らせには、まだ英語版がない場合があります。資料請求ページが一組そろっていても、サイト内のすべてのページに対応先があるとは限りません。言語切替の表示と移動先を、そのページの条件に合わせて決めます。

選択肢には、英語版を用意してから案内する、そのページでは未対応と分かるようにする、英語の案内ページへ移ることを明示する、といった考え方があります。どれを選べるかは現在の機能と運用によります。未準備ページで、対応する英語版があるような切替リンクを見せたままにしないでください。

架空のお知らせ例では、日本語の/ja/news/に対する英語ページ、英語メニューの行き先、対応先がないときの扱い、実際の切替結果が未確認です。未確認は「リンク切れを確認した」「英語ページが404だった」という記録ではありません。この例のpublished:falseも架空の公開前条件であり、実サイトを調査した結果ではありません。

Web更新担当は、対象のお知らせと不足を制作担当・内容の確認担当へ示し、どの行き先なら会社として案内できるかを決めます。行き先が未決定の部分を保留し、決まった後に同じページから操作を確かめ直します。英語版のないお知らせを理由に、すでに条件がそろった別ページまで一律に完成扱い・未完成扱いにする必要はありません。

日本語から英語へ、英語から日本語へ確かめる

公開前は許可された試験環境や確認方法を使い、まず日本語の対象ページを開きます。ページの目的と本文を読み、そこにある英語への切替リンクを使います。切替後に表示されたURL、見出しと本文が、対応する英語の資料請求ページかを確認してください。URLにenが含まれることだけでは、本文の確認は終わりません。

次に、英語ページのメニューから製品案内や資料請求へ移り、対象言語のページに到達するかを見ます。問い合わせボタンも実際に開き、到達先と利用条件を読みます。この段階はリンクと案内の確認で、送信や受付の試験ではありません。確認できない宛先や訳文は、確認済みの欄へ混ぜず残します。

最後に英語ページから日本語へ切り替え、意図した日本語ページへ戻るかを確認します。日本語から英語への一方向が合っていても、逆方向まで確かめたことにはなりません。同じ操作を、スマートフォンの折りたたみメニューと、広い画面のメニューでも行います。見えていない項目がある場合は、メニューを開いて先まで読みます。

本文を確かめる

対応する目的のページか。対象の言語で、内容と条件が確認されているか。

言語切替を確かめる

元のページから対応先へ移り、逆方向も意図したページへ戻るか。

メニューを確かめる

表示する文字とリンク先の言語が合うか。狭い画面でも必要な項目を開けるか。

問い合わせ先を確かめる

案内先が決まり、対象言語で利用できる条件が読めるか。実送信・受付の確認とは分ける。

不一致があれば、開始したページ、操作した項目、到達したURLと本文、使った画面幅を残します。「英語化できない」という一言でまとめず、本文の言語、選択メニュー、項目の行き先、テンプレートなど、どの箇所が未確認かを絞ります。同じ症状の投稿を見つけても、他人のテーマやプラグインの条件をそのまま自社の原因にしません。

たとえばWordPressのサポートには、Twenty Twenty-FourとPolylangなどを使った環境で、言語を切り替えてもメニューが英語のままという本人の相談があります。これは具体的な困りの例で、すべてのテーマで同じ原因が起きるという証拠や、特定の設定変更で解決するという報告ではありません。

公開可を判断した版を、公開操作が認められる担当が扱います。公開後は日本語版と英語版の実URLを開き、同じ本文・メニュー・切替・問い合わせ先をもう一度確かめます。下書きや試験環境で見えたことを、公開先でも確認済みと読み替えません。

公開後の更新では、対応ページと共通部分を見直す

日本語の資料請求条件を変えたら、対応する英語版も確認対象に戻します。資料名や利用条件だけでなく、ボタン、画像の説明、問い合わせ先の案内も対象です。英語を確認する担当が未確認なら、日本語の新しい内容と整合したと決めつけず、掲載範囲をどう扱うかを判断します。

メニューやヘッダーなどの共通部分を変えるときは、使っているページと言語を確認します。一つのページで英語メニューが合っただけで、他のすべてのテンプレートや画面幅まで合ったとは認定しません。変更が及ぶ対象を選んで、同じ言語切替と行き先の確認を行います。

翻訳原稿の版をどう残すかと、言語ページのどこへ移るかは関連しますが別の仕事です。まず本稿のページ対とリンクの対応を決め、そのうえで自社の原稿管理方法へつなげます。機能を導入した担当だけに任せず、誰が訳文を確認し、誰が公開を判断し、誰が窓口の条件を答えられるかを運用に含めてください。

制作や更新を相談する場合は、対象の一組のページ、現在のテーマと多言語機能、更新する人、案内したい言語、未対応ページと不明な問い合わせ先を示します。現在の仕組みを確認しながら必要な仕事を分けられます。翻訳確認・実装・保守などの支援範囲、費用と受付可否は、個別に確認してください。

まとめ：一組のページと、三つの行き先から始める

日本語と英語で公開するには、本文の翻訳だけでなく、対応ページへの切替、各言語のメニュー、問い合わせ先をそろえます。言語設定や機能追加だけを、公開できたという判断には使いません。

最初の行動は、資料請求など対象を一組選び、日本語版と英語版のURLを並べることです。その組について、言語切替の行き先、メニューの行き先、問い合わせ先を確認します。予定の対応を書いたことと、実ページで到達した結果は分けてください。

未対応のお知らせ、訳文の確認待ち、宛先が不明な窓口は、その範囲の公開判断を保留します。条件が決まったら同じ経路で確かめ直し、公開後の実URLでも見ます。本稿の架空例も、切替・問い合わせ・訳文確認の未確認を埋めずに、この判断方法を説明しています。