多言語 WordPress における画像メタデータとメディアの扱い

何が言語で変わり、何を共有すべきか

多言語 WordPress サイトには、通常 2 種類の画像データがあります。1 つは言語に向けたコンテンツで、代替テキスト、キャプション、そしてページの文脈でユーザーや検索エンジンに表示される説明文です。もう 1 つは共有されるメディアデータで、実際の画像ファイル、その技術的な添付ファイル記録、そしてページの言語ではなくファイル自体を説明するメタデータです。

この違いが重要なのは、共有される技術データを翻訳しても意味は向上せず重複だけが増える一方で、言語に向けたテキストを翻訳しないと画像がページの言語から切り離されてしまうからです。適切な境界は、そのフィールドがコンテンツとして読まれるのか、ファイル情報として読まれるのかで決まることが多いです。

代替テキスト: ファイル名ではなく意味を翻訳する

代替テキストは、説明的コンテンツとして扱われるため、WordPress で最も言語の影響を受けやすい画像フィールドです。多言語構成では、支援技術や検索システムがそのページの文脈で解釈するため、代替テキストは通常、画像が表示されるページの言語に合わせるべきです。

だからといって、すべての画像に各言語で異なる概念説明が必要というわけではありません。画像が純粋に装飾目的なら、代替テキストは空欄のままにするか、サイトのアクセシビリティ方針に従うべきで、意味のないフレーズに翻訳するべきではありません。画像が情報を伝える場合は、翻訳された代替テキストでその情報を対象言語で説明し、読者が使えない原文の表現を残さないようにします。

よくある失敗は、メディア項目が共有されているからという理由で、1 つの言語の代替テキストをすべての翻訳で使い回すことです。これではメディアライブラリは簡潔になりますが、画像と翻訳済みページ内容の関係が崩れます。もう 1 つの失敗は、周囲のページ本文をそのままにして代替テキストだけを機械的に翻訳することで、用語や製品名の不一致が生じることです。

キャプション: ページの物語の一部なら翻訳する

キャプションは、ファイルのメタデータというより本文に近い振る舞いをします。キャプションが読者に表示されるなら、それはページの言語に参加しているため、通常は他のコンテンツと一緒に翻訳すべきです。特に、キャプションが周囲のテキストに依存する文脈、出典、解釈を補う場合はそうです。

キャプションはフロントエンドで表示されるため、理解しやすさとレイアウトの両方に影響します。翻訳されたキャプションは原文より長くなったり短くなったりすることがあるため、実装者は 1 対 1 の見た目の一致を前提にするのではなく、改行や余白の違いを想定しておく必要があります。

キャプションがサイト内の複数箇所で参照元として使われる場合、翻訳の判断はより重要になります。1 つのキャプションを複数言語で使い回すと編集作業は減らせますが、すべての言語版が同じ表現を引き継ぐことになり、地域ごとの用語や法的・出典表記の要件に合わない可能性があります。

添付ファイルのメタデータ: ほとんどは共有、ただし言語を意識する場合もある

WordPress の添付ファイルのメタデータは、通常、ページの言語ではなくファイル自体を説明します。これには、アップロードされたメディアに関連する技術的属性や、メディアライブラリにファイルを保存する添付ファイル記録が含まれます。多くの多言語ワークフローでは、基盤となるアセットはどの言語でも同じなので、このデータは共有のままにしておくべきです。

実務上の例外は、添付ファイル記録にメディアライブラリやフロントエンドで表示されるユーザー向けテキストが含まれている場合です。その場合、そのテキストはコンテンツとして振る舞うため、翻訳が必要になることがあります。重要なのは、そのフィールドが技術的識別子として使われているのか、表示される編集用コピーとして使われているのかです。

この違いは保守にも影響します。共有された添付ファイルデータは重複を減らし、更新を同期しやすくしますが、説明文とファイルの識別を分けないワークフローでは、言語ごとの編集管理が難しくなることがあります。言語を意識した添付ファイル記録は編集者の制御を高めますが、同じ画像がある言語で更新されても他の言語に反映されない場合、版ごとの差異が生じるリスクも高まります。

ファイル名と画像 SEO: 発見には有用だが、通常は翻訳対象ではない

画像ファイル名はファイル層の一部なので、通常は言語ごとに翻訳するのではなく共有されます。アップロード後にファイル名を変更すると、ファイルパス、本文中の参照、派生 URL などを整合させる必要があり、運用が複雑になる可能性があります。そのため、ファイル名は言語固有のコンテンツというより技術的識別子として扱う方が適しています。

画像 SEO の観点では、ファイル名はアセットの命名や整理に関わるため、依然として重要です。ただし、多言語 WordPress では、より強い言語シグナルは通常、周囲のページコンテンツ、翻訳された代替テキスト、キャプション、そしてページ自体のルーティングや正規化構造から得られます。周囲の表示テキストが別の言語のままなら、ファイル名だけを翻訳しても画像が十分にローカライズされたことにはなりません。

トレードオフは明快です。ファイル名を翻訳するとメディアライブラリでの可読性は上がるかもしれませんが、再利用、キャッシュ、言語版をまたぐ参照が複雑になることもあります。ファイル名を共有のままにしておけば安定性が保たれ、複数の翻訳で使われる 1 つのファイルとして管理しやすくなります。

再利用可能なメディア: 1 つのファイル、複数の言語文脈

再利用可能なメディアは、多言語 WordPress が運用上おもしろくなる部分です。1 枚の画像を複数の翻訳で使えますが、言語版ごとに異なる説明文、異なる周辺コピー、あるいはレイアウト変更に応じた別の切り抜きが必要になることがあります。共有されるファイルは同じままでも、言語固有の見せ方はその周囲で変わります。

この分離が有用なのは、バイナリアセットの不必要な重複を避けられるからです。また、メディアライブラリとコンテンツ層が同じ翻訳モデルに従う必要がないことも意味します。画像はグローバルに共有しつつ、それを説明するページレベルのメタデータは言語ごとにローカライズできます。

主な失敗は、共有メディアが共有された意味を意味すると思い込むことです。ある言語版ではうまく機能する画像でも、文化的・編集的文脈が変われば、別の言語では別のキャプション、代替テキスト、あるいは別の代替画像が必要になることがあります。再利用は効率的ですが、言語適合性を上書きすべきではありません。

何を翻訳するかを決める方法

実践的なルールは、読者がページのメッセージの一部として解釈するものは翻訳し、ファイル自体を識別または保存するものは共有のままにすることです。つまり、代替テキストとキャプションは通常翻訳され、基盤となる画像ファイルと多くの添付ファイルのメタデータは共有のままです。

フィールドの位置づけが中間的な場合は、2 つの質問をします。そのフィールドはユーザーに表示されるか、そしてその意味はページの言語に依存するか、です。どちらかに「はい」と言えるなら、翻訳が適切な場合があります。ファイル管理や表示処理を支えるだけのフィールドなら、通常はグローバルのままにしておくべきです。

この判断は編集ワークフローにも影響します。画像テキストをローカライズするチームは、翻訳された説明をページ更新と整合させる仕組みが必要です。メディアを共有のままにするチームは、新しい言語版で既存アセットを再利用するのか、それとも別の画像やキャプションを用意するのかを明確に定める必要があります。