只在 / 協商語言，並確保 /en/ 和 /fr/ 等明確網址一律提供其指定的語言。本指南說明 Mac 桌面版發布者如何指定此行為、保留可供探索的文件連結，並測試結果。

本文的範例是一組合成的公開文件集，包含一份簡短形狀排列指南的英文和法文版本。其根頁面是語言選擇頁，簡介文字可依請求調整。所有範例網址都描述一種建議的配置，並非聲稱這些網址目前託管了相關頁面。

變更語言設定前，先定義網址行為

先訂定一份精簡的路由契約。在此範例中，根頁面協助讀者選擇語言，而兩個明確路徑則包含完整的翻譯文件。Google 建議為不同語言版本使用個別網址，並建議不要根據推測的語言，自動將讀者重新導向到不同版本。可見的連結能讓讀者自行選擇。管理多地區和多語言網站。

請求路徑 預期回應 語言偏好的影響
/ 含簡短簡介的語言選擇器 可變更簡介和建議連結
/en/ 完整英文文件 文件語言不變
/fr/ 完整法文文件 文件語言不變
未發布的路徑 找不到頁面的回應 不得悄悄改為提供其他文件

將此表視為實作說明。只有在確認請求目標是根頁面後，才套用語言選擇。若在每個頁面請求前都執行通用規則，便可能覆蓋明確選擇，違反契約。

例如，跟隨 /fr/ 的讀者，即使請求偏好英文，仍應收到法文文件。英文偏好在尚未決定的入口頁面很有用；其他位置的明確路徑已經表明了選擇。本文全程採用此優先順序作為設計建議。

每個頁面都要顯示兩種語言的連結。在根頁面上，建議一種語言可讓讀者更容易做出第一次選擇，同時不隱藏另一個選項。在完整文件中，語言切換器應直接連到相對應的文件。

選擇可預期的根頁面語言政策

Accept-Language 表示偏好的回應語言，並可帶有 fr;q=0.9,en;q=0.5 等品質權重。它不要求伺服器提供所有請求的語言。品質值為零表示不可接受。Content-Language 說明所傳回表示內容的預期受眾；它不會選擇路由。RFC 9110：HTTP 語意，第 8.5、12.4.2 和 12.5.4 節。

設定任何內容前，先記錄支援的語言集和後備選項。在此範例中，使用英文和法文簡介；若請求沒有可用的相符語言，則提供英文簡介和兩種語言選項。這個後備選項是示範性的發布選擇，並非 HTTP 規定。

使用具有明確政策的語言比對實作。RFC 4647 區分篩選和查找：查找會選出一個結果，依優先順序處理請求的範圍，並在尋找相符項目時逐步移除子標籤。它也要求使用查找的應用程式定義預設行為。因此，請求 fr-CA 可透過查找對應至支援的通用 fr 簡介。RFC 4647：語言標籤比對，第 3.4–3.4.1 節。

不要透過搜尋標頭中第一次出現的 fr 或 en 來選擇語言。這種捷徑會忽略權重和排除項目。比對層應剖析偏好、考量權重為零的排除項目，再套用已記錄的後備選項。

根頁面請求偏好 此範例中的預期結果
沒有標頭 英文簡介並提供兩種選項
fr 法文簡介並提供兩種選項
fr-CA,fr;q=0.9,en;q=0.5 法文簡介
en;q=0.9,fr;q=0.2 英文簡介
de 後備語言選擇器
fr;q=0,en;q=1 英文簡介；不選擇法文
*;q=0 明確定義未相符語言的處理方式

最後一列需要審慎決定。對此選擇器設計，應指定當請求排除所有語言時，提供後備選擇器，因為應用程式選擇不遵從該偏好，而不是宣稱英文與之相符。若要求嚴格協商，則應定義並測試相應的不可接受回應行為。無論採用哪種方式，都要避免意外地將零視為一般的低優先偏好。

讓文件語言、連結和搜尋註記保持一致

每份 HTML 文件都應將文件的 lang 屬性設為實際的主要語言：英文頁面使用 en，法文頁面使用 fr。WHATWG 將 lang 定義為元素內容和文字屬性的主要語言；若未指定，則從父元素繼承。只有語言前綴並不等於完成此宣告。HTML 標準：lang 和 xml:lang 屬性。

也要檢查導覽連結，而不只是頁面文字。相對網址會依據 WHATWG URL 標準，以基底網址解析。例如，若文件沒有其他基底，從 https://example.com/en/ 出發的 fr/ 會解析為 https://example.com/en/fr/；/fr/ 則會解析至該來源的法文路徑。可見的切換器應使用預期的絕對路徑。URL 標準：URL 撰寫和解析。

搜尋註記有不同用途。Google 支援透過 HTML、HTTP 標頭或網站地圖標註等效語言版本。選擇一種易於管理的方法。每個版本都應以完整網址標示自身及對應版本，且各版本應透過這些註記互相連結。根頁面選擇器可作為 x-default 目標。告知 Google 網頁的本地化版本。

這組合成文件的註記對應如下：

註記 合成目標
en https://example.com/en/
fr https://example.com/fr/
x-default https://example.com/

透過發布系統支援的註記機制輸入這些關聯。此對應表是規格，不是可執行標記。x-default 不會設定伺服器協商，也不會提供翻譯。Google 也表示，它會以演算法判定頁面語言，而不會使用 hreflang 或 HTML lang 來偵測語言。告知 Google 網頁的本地化版本。

無論根頁面的內容如何調整，都要讓完整翻譯能獨立存取。Google 說明其檢索器發出的請求不帶 Accept-Language，並警告，語系自適應頁面可能使某些變體無法被發現。可靠的後備選項和直接的語言網址，能解決這項探索問題，不必要求檢索器請求不同版本的根頁面簡介。Google 如何檢索語系自適應頁面。

讓快取的根頁面回應遵循語言選擇

若根頁面選擇取決於 Accept-Language，根頁面回應都應包含 Vary: Accept-Language，包括後備回應。保留任何既有的變化欄位。法文根頁面回應的範例可包含以下標頭片段；這不是完整的 HTTP 訊息：RFC 9110：HTTP 語意，第 12.5.5 節。

Content-Type: text/html; charset=utf-8
Content-Language: fr
Vary: Accept-Language

RFC 9111 規定，快取若要在不重新驗證的情況下重用已儲存的回應，必須先比對 Vary 指定的請求欄位。由於根頁面網址保持相同，簡介卻會改變，因此這點很重要。Vary 說明選擇輸入資料，但不會實作語言比對器。RFC 9111：HTTP 快取，第 4.1 節。

此設計不會讓 /en/ 和 /fr/ 的文件依 Accept-Language 變化。請依照路由契約檢查完整的傳送路徑，包括任何共用快取。作為實用的診斷方式，先後交替發出英文和法文根頁面請求，再反轉順序。若根頁面反覆傳回前一次請求的語言，就應一併檢查快取行為和路由。

在 Mac 上測試契約

先在公開的示範來源上準備三個合成頁面。以下測試要求該來源在 /、/en/ 和 /fr/ 只包含此示範文件集。它不會建立頁面或設定主機。上述示範性的 example.com 網址並非可運作的測試安裝環境。

開啟 Mac 的 Terminal app，執行 curl --version 確認 curl 可用。接著貼上以下完整的 shell 診斷指令。系統提示時，輸入示範來源網址，包括 https://，不要加上路徑或結尾斜線。

printf 'Public demo origin, without a trailing slash: '
IFS= read -r demo_origin
case "$demo_origin" in
  https://*) ;;
  *) printf 'Enter an HTTPS origin.\n' >&2; exit 1 ;;
esac

for demo_path in / /en/ /fr/; do
  for demo_language in '' 'en' 'fr' 'fr-CA,fr;q=0.9,en;q=0.5' 'en;q=0.9,fr;q=0.2' 'de' 'fr;q=0,en;q=1'; do
    printf '\nPath: %s | Accept-Language: %s\n' \
      "$demo_path" "${demo_language:-absent}"
    curl --silent --show-error --connect-timeout 5 --max-time 15 \
      --dump-header - --header "Accept-Language: $demo_language" \
      "$demo_origin$demo_path" || exit 1
  done
done

此診斷會輸出回應標頭和本文。Curl 的 --header 會提供偏好；空值則會移除該標頭。--dump-header - 會將標頭輸出至標準輸出，而時間限制則界定每次傳輸的上限。此處刻意不跟隨重新導向，讓意外的重新導向保持可見。curl — 使用方式。

此指令碼的 shell 語法已經過檢查；本文不聲稱已部署示範環境或驗證即時語言路由結果。若 curl 傳輸失敗，指令碼會停止；但 HTTP 錯誤回應仍可能出現在輸出中，必須檢查。

將根頁面回應與偏好表進行比較。接著，無論提供何種偏好，都要檢查每個 /en/ 回應是否為英文內容，以及每個 /fr/ 回應是否為法文內容。檢查狀態碼、非預期的 Location 欄位、傳回的語言宣告，以及實際文件文字。即使標頭正確，只要本文錯誤，結果仍不合格。

最後，在瀏覽器中開啟兩個明確網址。分別點選語言切換器、重新載入目的頁面，並檢查網址列。這能找出直接請求成功時不會發現的導覽錯誤。另行測試未發布的路徑，確認它不會悄悄顯示其中一份完整文件。

無法協商時，使用穩定的選擇器

此設計需要能讀取請求標頭並選擇回應的服務層。WHATWG 的文件語言和 URL 機制用來描述文件和網址；加入 lang 屬性或更改連結文字，本身不會建立 HTTP 協商。依請求選擇內容的工作，應由 HTTP 傳送設定負責。HTML 標準、RFC 9110：HTTP 語意。

若發布系統不提供這類服務能力，請使用固定的根頁面選擇器，直接連到完整的語言頁面。這能保留讀者選擇的能力，也符合 Google 對個別語言網址和可見切換連結的建議。本文不預設任何特定發布產品具備協商功能。管理多地區和多語言網站。

實務上的驗收標準很簡單：偏好設定可協助選擇根頁面內容，而明確的語言連結仍應是可靠的目的地。完成時應具備已記錄的後備選項、相符的文件宣告、相互對應的語言註記，以及逐項請求證明路由契約成立的證據。

資料來源