翻訳済みドキュメントページは、共通する内容と目的に基づいて対応付け、各言語の正確なURLを記録します。スラッグが異なっていても問題ありません。このMacでのワークフローを使えば、公開ドキュメントの編集者は対応関係を作成し、正確な言語別リンクと検索用アノテーションを準備できます。

スラッグを一致させる必要がない理由

英語のドキュメントで、色のついた正方形を並べてグリッドを作る方法を説明しているとします。フランス語訳でも同じ作業を説明していますが、2つのアドレスの末尾は異なります。Googleは、URLにローカライズされた語句を使うことを明示的に認めており、言語バージョンごとに別々のURLを使うよう推奨しています。パスを一致させるために翻訳ページの名前を変える必要はありません。多地域向け・多言語サイトの管理。

答えるべき問いは2つあります。「これらのURLは同一か」と「これらのドキュメントは互いの翻訳か」です。WHATWG URL Standardでは、シリアライズされたURLを比較してURLの同一性を定義しています。この比較では、異なるアドレス間に翻訳関係があるかどうかは判断できません。このワークフローでは、ドキュメントを見て関係を判断し、その関係を明示的に記録します。URL Standard、URLの同等性。

以下の例は、example.com配下の架空の公開ドキュメントアドレスです。提示するのは対応付け案であり、実際に取得したページではありません。目的は、英語とフランス語の同等な手順を結び付けながら、それぞれのページの既存アドレスを維持することです。

Macで対応関係を記録する

まず、ドキュメントのペアを1つ用意します。元のページと翻訳候補をSafariの別々のタブで開き、ローカルの対応表も並べておきます。両バージョンの全文と、実際に反映する段階で言語間の関係やページのメタデータを管理する公開設定へのアクセスが必要です。

正確なアドレスを記録する

SafariでCommand-Lを押してSmart Searchフィールドを選択し、続けてCommand-Cを押してアドレスをコピーします。翻訳ページが読み込まれた後、同じ操作を繰り返します。Appleの案内では、どちらのショートカットも説明されています。移動後に表示されたアドレスを記録しておけば、予期しない遷移先に気付く手がかりにもなります。MacのSafariのキーボードショートカットとジェスチャ。

少数のページなら、TextEditで十分です。新規書類を作成し、フォーマット > プレーンテキストにするを選んで、translation-map.txtとして保存します。既存のリッチテキスト書類を変換すると書式が削除されるため、この記録には新しい書類を使ってください。これらの操作はAppleのTextEditの手順に沿っています。MacのTextEditで書類を作成、開く、変換する。

元の作業内容が分かる、安定したドキュメント識別子を使います。以下は記録例の全体を示したもので、公開システムが自動で読み込む設定ファイルではありません。

Document ID: tile-grid
Reader task: Arrange a four-column grid of colored squares
English URL: https://example.com/en/docs/arrange-tiles
French URL: https://example.com/fr/guides/disposer-les-carres
English language code: en
French language code: fr
Scope check: Same instructions, diagram, and document edition
Mapping decision: Translation pair

タイトルやスラッグが変わっても、この識別子を基準にできます。アドレスは別々のフィールドに記録し、一方から他方を作らないでください。この例で/en/を/fr/に置き換えると、未確認のアドレスができてしまい、実際の翻訳ページのパスを反映できません。

ドキュメントが同じ作業を完了できるか確認する

序文、手順、図のラベル、例、版を比較します。翻訳後のタイトルが一語一句似ている必要はありません。代わりに、もう一方の言語を選んだ読者が、同じ作業について同等の手順を読めるかを確認します。

ページを対応表に加える前に、次の判断表を使います。同じ内容の別バージョンを特定する必要性に基づいた編集用の補助表です。

確認できた内容 対応付けの判断
同じグリッドの手順と同じ版で、テキストが翻訳されている 翻訳ペアとして記録する
一方はグリッド、もう一方は色の選び方を扱っている 別々のドキュメントとして扱う
一方の翻訳が以前の版を説明している グループ化する前に版の違いを解決する
ナビゲーションだけが翻訳されている メインのドキュメントが完全に翻訳済みとは記録しない
対応するドキュメントがない このドキュメントの対応表では、その言語を未掲載のままにする

たとえば、複数のお絵描きアクティビティへのリンクを載せたフランス語の概要ページは、グリッドの具体的な手順を記した英語ページの代わりにはなりません。未翻訳として残っていることを、コンテンツ作成の課題として記録します。広範な内容を扱うリンク先が案内として役立つ場合はありますが、この対応付けに必要な同等のドキュメントにはなりません。

対応付けたページを読者とGoogleのために関連付ける

ローカルの記録が、編集上の対応関係を示す基準になります。公開ページにも、その関係を表す方法が必要です。まず、読者を対応するページへ直接案内する、目に見える言語リンクを設けます。Googleは、読者が言語を選べるよう、言語バージョン同士をリンクすることを推奨し、推定した言語に基づく自動リダイレクトは避けるよう案内しています。多地域向け・多言語サイトの管理。

検索用アノテーションには、HTML要素、HTTPレスポンスヘッダー、XMLサイトマップの3つの方法がGoogleによりサポートされています。保守しやすい方法を1つ選んでください。各言語バージョンには、自分自身と代替ページを完全修飾URLで示し、相互リンクを設定する必要があります。ページのローカライズ版をGoogleに知らせる。

HTMLページの場合は、代替ページのリンクを準備する

WHATWG HTML Standardでは、alternateの値を別のhreflangにしたものが、翻訳を示すと定義されています。以下は架空のペアを示すHTMLメタデータの断片で、各ページに既にあるhead要素内に置きます。HTMLドキュメント全体ではありません。HTML Standard、リンクタイプ「alternate」。

<link rel="alternate" hreflang="en" href="https://example.com/en/docs/arrange-tiles">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/guides/disposer-les-carres">

このペアを両方のページに同じように記述します。スラッグを含め、リンク先のURLはそれぞれ異なります。Googleのドキュメントでは、相互リンクを必須とし、enやfrのような言語のみのコードもサポートしています。ページのローカライズ版をGoogleに知らせる。

PDFの場合は、サポートされている公開方法を使う

PDFでは、前述の断片をHTMLのheadに設定できません。Googleは、HTML以外のファイル向けにHTTP Linkレスポンスヘッダーを案内しています。架空のPDFペアの場合、ヘッダーフィールド全体は次のとおりです。ページのローカライズ版をGoogleに知らせる。

Link: <https://example.com/en/files/tile-grid.pdf>; rel="alternate"; hreflang="en", <https://example.com/fr/fichiers/grille-de-carres.pdf>; rel="alternate"; hreflang="fr"

各PDFのレスポンスにこのフィールドを設定します。RFC 8288では、山括弧内のリンク先やhreflangパラメーターなど、HTTPリンクの構文が定義されています。これらはレスポンスの設定です。PDF内の見えるテキストにヘッダーを書き込んでも設定されません。RFC 8288: Web Linking。

公開システムでHTMLメタデータやレスポンスヘッダーを編集できない場合は、Googleがサポートする言語アノテーション付きのサイトマップを使えます。各URLエントリには、自分自身を含むすべてのバージョンを列挙します。公開システムまたはその保守担当者を通じて、ドキュメントに記載されたサイトマップ構造を使用してください。ローカルの対応表だけでは、これらの方法はどれも実装されません。ページのローカライズ版をGoogleに知らせる。

翻訳関係をリダイレクトやcanonicalと分けて扱う

言語の代替ページ、優先する重複URL、移動したページは、それぞれ異なる関係を表します。この違いを把握しておけば、意図した対応付けの変更によって、読者が選んだドキュメントから離れてしまうのを防げます。

仕組み ドキュメント上の目的 この作業での用途
rel="alternate"とhreflang 言語別の代替ページを特定する 対応付けた翻訳を関連付ける
rel="canonical" 重複または非常によく似たページ群の中から優先URLを示す 該当する言語内で重複したアドレスに対処する
リダイレクトレスポンスのLocation リダイレクト先を示す 移動したアドレスに対処する
Content-Language 表現が対象とする言語の読者を示す レスポンスの対象読者を示す
Content-Location 返された表現に対応するリソースを示す 表現の場所を記述する

hreflangを使う場合、Googleは同じ言語のcanonical URLを推奨しています。同じ言語に該当するものがない場合は、最適な代替URLを指定します。内容が異なる翻訳ドキュメントの場合、優先する言語別URLごとに、自身を参照するcanonicalを設定するのが分かりやすい方法です。英語が先に書かれたからといって、フランス語のcanonicalを英語に向けないでください。rel="canonical"などを使ってcanonical URLを指定する方法。

RFC 9110では、リダイレクトレスポンスのLocation、Content-Language、Content-Locationをそれぞれ別に定義しています。最後のものは表現のメタデータであり、リンク先URLの代わりではありません。これらのフィールドはいずれも単独でドキュメントの翻訳ペアを列挙しないため、その関係には代替ページのリンクを使います。RFC 9110: HTTP Semantics。

双方向のリンクを確認し、対応表を保守する

対応表を実装担当者に渡す前に、以下の項目を確認します。後日公開設定を変更した場合も、公開結果を使って同じ確認を繰り返してください。記録が正しいことと公開メタデータが正しいことは、別々に確認が必要です。

  1. 記録した両方のアドレスを開き、実際のドキュメント内容を比較する。
  2. 英語からフランス語へ、次に戻る言語リンクをたどり、それぞれが特定の対応ページに到達することを確認する。
  3. 設定した代替URLと対応表を、1文字ずつ照合する。
  4. 自身も含め、両バージョンが同じ翻訳セットを示していることを確認する。
  5. 各言語のcanonical設定を個別に確認する。
  6. アドレスが変わった場合は、対応表と、そのペア内で当該アドレスを参照するすべての箇所を更新する。

URLの整理は慎重に行ってください。RFC 9110では、正規化規則の下でスキームとホスト名の大文字・小文字は区別されませんが、その他の要素は大文字・小文字を区別して比較されます。2つの記録の見た目をそろえるためだけに、パスを小文字にしたり末尾のスラッシュを削除したりせず、確認済みのリンク先を維持してください。RFC 9110、HTTP(S)の正規化と比較。

この架空のペアで目指すのは、同等の内容と双方向で機能するリンクを備えた、2つの正確なアドレスを結び付ける安定したtile-grid記録です。将来、翻訳やスラッグが変わったときに対応関係を意図的に更新できるよう、この記録をドキュメントの保守メモと一緒に保管します。

出典