Die Sprache wird nur unter / ausgehandelt; explizite URLs wie /en/ und /fr/ liefern immer die jeweils angegebene Sprache. Diese Anleitung zeigt einem Desktop-Publisher auf dem Mac, wie sich dieses Verhalten festlegen, auffindbare Dokumentlinks erhalten und das Ergebnis testen lässt.

Das durchgearbeitete Beispiel ist eine synthetische öffentliche Dokumentsammlung mit englischen und französischen Fassungen einer kurzen Anleitung zum Anordnen von Formen. Die Startseite ist eine Sprachauswahlseite, deren Einführungstext sich an die Anfrage anpassen kann. Alle Beispieladressen beschreiben eine vorgeschlagene Konfiguration; sie behaupten nicht, dass unter diesen Adressen derzeit Seiten gehostet werden.

URL-Verhalten festlegen, bevor Spracheinstellungen geändert werden

Beginnen Sie mit einem kleinen Routing-Vertrag. In diesem Beispiel hilft die Startseite Lesern bei der Sprachauswahl, während die beiden expliziten Pfade das vollständige übersetzte Dokument enthalten. Google empfiehlt separate URLs für Sprachversionen und rät davon ab, Leser aufgrund einer vermuteten Sprache automatisch zwischen diesen Versionen umzuleiten. Sichtbare Links überlassen die Wahl den Lesern. Verwaltung multiregionaler und mehrsprachiger Websites.

Angeforderter Pfad Vorgesehene Antwort Auswirkung der Spracheinstellung
/ Sprachauswahl mit kurzer Einführung Einführung und vorgeschlagener Link können sich ändern
/en/ Vollständiges englisches Dokument Dokumentsprache bleibt unverändert
/fr/ Vollständiges französisches Dokument Dokumentsprache bleibt unverändert
Ein nicht veröffentlichter Pfad Antwort für eine fehlende Seite Darf nicht stillschweigend zu einem anderen Dokument werden

Betrachten Sie diese Tabelle als Implementierungsauftrag. Wählen Sie die Sprache erst aus, nachdem geprüft wurde, ob die Anfrage die Startseite betrifft. Eine allgemeine Regel, die vor jeder Seitenanfrage greift, kann eine explizite Auswahl überschreiben und den Vertrag brechen.

Wer beispielsweise /fr/ aufruft, sollte weiterhin das französische Dokument erhalten, auch wenn die Anfrage Englisch bevorzugt. Die englische Präferenz ist am noch unentschiedenen Einstiegspunkt nützlich; der explizite Pfad gibt die Entscheidung an anderer Stelle bereits vor. Diese Priorität ist die Gestaltungsempfehlung, die im gesamten Artikel verwendet wird.

Lassen Sie beide Sprachlinks auf jeder Seite sichtbar. Auf der Startseite kann eine vorgeschlagene Sprache die erste Wahl erleichtern, ohne die andere Option zu verbergen. Auf den vollständigen Dokumentseiten sollte der Sprachumschalter direkt zum entsprechenden Dokument führen.

Eine vorhersehbare Richtlinie für die Sprache der Startseite wählen

Accept-Language gibt bevorzugte Antwortsprachen an, mit Gewichtungen wie fr;q=0.9,en;q=0.5. Daraus folgt nicht, dass ein Server jede angeforderte Sprache bereitstellen muss. Ein Qualitätswert von null bedeutet „nicht akzeptabel“. Content-Language beschreibt die vorgesehene Zielgruppe der zurückgegebenen Repräsentation; es wählt keine Route aus. RFC 9110: HTTP-Semantik, Abschnitte 8.5, 12.4.2 und 12.5.4.

Notieren Sie vor jeder Konfiguration die unterstützten Sprachen und die Ausweichregel. Verwenden Sie in diesem Beispiel englische und französische Einleitungen; wenn die Anfrage keine brauchbare Übereinstimmung enthält, wird eine englische Einleitung mit beiden Sprachoptionen angezeigt. Diese Ausweichregel ist eine beispielhafte redaktionelle Entscheidung und keine HTTP-Anforderung.

Verwenden Sie eine Sprachabgleich-Implementierung mit einer ausdrücklich festgelegten Richtlinie. RFC 4647 unterscheidet zwischen Filterung und Lookup: Beim Lookup wird ein Ergebnis ausgewählt, wobei angeforderte Bereiche in Prioritätsreihenfolge berücksichtigt und Unter-Tags schrittweise entfernt werden, um eine Übereinstimmung zu finden. Außerdem müssen Anwendungen, die Lookup verwenden, ihr Standardverhalten festlegen. So kann eine Anfrage für fr-CA durch Lookup zu einer unterstützten allgemeinen fr-Einleitung führen. RFC 4647: Abgleich von Sprach-Tags, Abschnitte 3.4–3.4.1.

Wählen Sie die Sprache nicht aus, indem Sie den Header nach dem ersten Vorkommen von fr oder en durchsuchen. Diese Abkürzung berücksichtigt weder Gewichtungen noch Ausschlüsse. Die Abgleichschicht sollte die Präferenzen analysieren, Ausschlüsse mit Gewicht null berücksichtigen und dann die dokumentierte Ausweichregel anwenden.

Sprachpräferenz der Startseitenanfrage Erwartetes Ergebnis in diesem Beispiel
Header fehlt Englische Einleitung mit beiden Optionen
fr Französische Einleitung mit beiden Optionen
fr-CA,fr;q=0.9,en;q=0.5 Französische Einleitung
en;q=0.9,fr;q=0.2 Englische Einleitung
de Ausweich-Sprachauswahl
fr;q=0,en;q=1 Englische Einleitung; Französisch wird nicht ausgewählt
*;q=0 Ausdrücklich festgelegte Behandlung nicht übereinstimmender Sprachen

Die letzte Zeile erfordert eine bewusste Entscheidung. Legen Sie für diese Auswahlseite fest, dass eine Anfrage, die alle Sprachen ausschließt, die Ausweich-Sprachauswahl erhält, weil die Anwendung diese Präferenz nicht erfüllt, statt zu behaupten, Englisch passe dazu. Wenn stattdessen eine strikte Aushandlung erforderlich ist, definieren und testen Sie das entsprechende Verhalten für nicht akzeptable Sprachen. In jedem Fall sollte der Wert null nicht versehentlich als gewöhnliche niedrige Präferenz behandelt werden.

Dokumentsprache, Links und Suchmaschinenannotationen aufeinander abstimmen

Setzen Sie für jedes HTML-Dokument das Attribut lang der Seite auf ihre tatsächliche Hauptsprache: en für die englische und fr für die französische Seite. WHATWG definiert lang als Hauptsprache des Inhalts und der Textattribute eines Elements; fehlt die Angabe, wird sie vom übergeordneten Element übernommen. Ein Sprachpräfix allein deklariert die Sprache nicht. HTML-Standard: Die Attribute lang und xml:lang.

Prüfen Sie neben dem Seitentext auch die Navigationslinks. Relative URLs werden gemäß dem WHATWG-URL-Standard relativ zu einer Basis-URL aufgelöst. Beispielsweise wird fr/ ohne eine abweichende Dokumentbasis von https://example.com/en/ zu https://example.com/en/fr/ aufgelöst; /fr/ führt zum französischen Pfad des Ursprungs. Verwenden Sie für den sichtbaren Sprachumschalter den vorgesehenen absoluten Pfad. URL-Standard: Schreiben und Parsen von URLs.

Suchmaschinenannotationen erfüllen einen anderen Zweck. Google unterstützt Annotationen für gleichwertige Sprachversionen über HTML, HTTP-Header oder eine Sitemap. Wählen Sie eine praktikable Methode. Jede Version sollte sich selbst und ihre Gegenstücke mit vollständig qualifizierten URLs angeben; außerdem sollten die Versionen über diese Annotationen aufeinander verweisen. Die Startseite mit der Sprachauswahl kann das Ziel von x-default sein. Google über lokalisierte Versionen Ihrer Seite informieren.

Für die synthetische Sammlung gilt folgende Zuordnung der Annotationen:

Annotation Synthetisches Ziel
en https://example.com/en/
fr https://example.com/fr/
x-default https://example.com/

Tragen Sie diese Beziehungen über den vom Publikationssystem unterstützten Annotationsmechanismus ein. Die Zuordnung ist eine Spezifikation, kein ausführbarer Markup-Code. x-default konfiguriert weder die Serveraushandlung noch stellt es eine Übersetzung bereit. Google erklärt außerdem, dass die Sprache einer Seite algorithmisch ermittelt wird und weder hreflang noch HTML-lang zu ihrer Erkennung verwendet werden. Google über lokalisierte Versionen Ihrer Seite informieren.

Halten Sie die vollständigen Übersetzungen unabhängig von der Anpassung der Startseite zugänglich. Google dokumentiert, dass sein Crawler Anfragen ohne Accept-Language sendet, und weist darauf hin, dass manche Varianten möglicherweise unentdeckt bleiben, wenn Seiten sich an das Gebietsschema anpassen. Eine zuverlässige Ausweichregel und direkte Sprach-URLs lösen dieses Auffindbarkeitsproblem, ohne dass ein Crawler unterschiedliche Einleitungen der Startseite anfordern muss. Wie Google Seiten mit Gebietsschema-Anpassung crawlt.

Cache-Antworten der Startseite an die Sprachauswahl anpassen

Wenn die Sprachauswahl der Startseite von Accept-Language abhängt, fügen Sie den Startseitenantworten Vary: Accept-Language hinzu, auch der Ausweichantwort. Behalten Sie bereits vorhandene Variationsfelder bei. Eine beispielhafte französische Startseitenantwort würde den folgenden Header-Ausschnitt enthalten; er ist keine vollständige HTTP-Nachricht: RFC 9110: HTTP-Semantik, Abschnitt 12.5.5.

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

RFC 9111 verlangt von einem Cache, die in Vary genannten Anfragefelder abzugleichen, bevor eine gespeicherte Antwort ohne erneute Validierung wiederverwendet wird. Das ist wichtig, weil die URL der Startseite gleich bleibt, während sich ihre Einleitung ändert. Vary beschreibt die Auswahlkriterien; es implementiert nicht den Sprachabgleich. RFC 9111: HTTP-Caching, Abschnitt 4.1.

Bei /en/ und /fr/ hängt dieses Konzept das Dokument nicht von Accept-Language ab. Prüfen Sie den gesamten Auslieferungspfad einschließlich gemeinsam genutzter Caches anhand des Routing-Vertrags. Als praktische Diagnose können Sie abwechselnd englische und französische Startseitenanfragen senden und dann die Reihenfolge umkehren. Liefert die Startseite wiederholt die zuvor angeforderte Sprache, sollten Cache-Verhalten und Routing gemeinsam untersucht werden.

Den Vertrag auf einem Mac testen

Bereiten Sie zuerst die drei synthetischen Seiten auf einem öffentlich erreichbaren Demonstrations-Ursprung vor. Für den folgenden Test muss dieser Ursprung ausschließlich die Demonstrationssammlung unter /, /en/ und /fr/ enthalten. Der Test erstellt keine Seiten und konfiguriert keinen Host. Die oben gezeigten beispielhaften example.com-Adressen sind keine funktionierende Testinstallation.

Öffnen Sie auf dem Mac die App Terminal und führen Sie curl --version aus, um zu prüfen, ob curl verfügbar ist. Fügen Sie anschließend die folgende vollständige Shell-Diagnose ein. Geben Sie bei der Aufforderung den Ursprung der Demonstrationsumgebung einschließlich https:// ein, ohne Pfad und ohne abschließenden Schrägstrich.

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

Diese Diagnose gibt Antwort-Header und -Bodies aus. Curl verwendet mit --header die Präferenz; ein leerer Wert entfernt diesen Header. --dump-header - gibt Header auf der Standardausgabe aus, und die Zeitlimits begrenzen jede Übertragung. Das Folgen von Weiterleitungen ist absichtlich nicht aktiviert, damit eine unerwartete Weiterleitung sichtbar bleibt. curl — Verwendung.

Die Shell-Syntax des Skripts wurde geprüft; eine Demonstrationsbereitstellung oder ein tatsächliches Ergebnis des Sprach-Routings wird hier nicht behauptet. Bei einem fehlgeschlagenen curl-Transfer bricht es ab. Eine HTTP-Fehlerantwort kann dennoch in der Ausgabe erscheinen und muss geprüft werden.

Vergleichen Sie die Antworten der Startseite mit der Präferenztabelle. Prüfen Sie anschließend bei jeder Antwort auf /en/, ob der Inhalt englisch ist, und bei jeder Antwort auf /fr/, ob der Inhalt französisch ist, unabhängig von der angegebenen Präferenz. Prüfen Sie Statuscodes, unerwartete Location-Felder, die zurückgegebene Sprachdeklaration und den tatsächlichen Dokumenttext. Ein korrekter Header mit falschem Inhalt bedeutet weiterhin, dass der Test fehlgeschlagen ist.

Öffnen Sie abschließend beide expliziten URLs in einem Browser. Folgen Sie jedem Sprachumschalter, laden Sie das Ziel neu und prüfen Sie die Adressleiste. So finden Sie Navigationsfehler, die bei einer erfolgreichen direkten Anfrage unentdeckt bleiben würden. Testen Sie einen nicht veröffentlichten Pfad separat und bestätigen Sie, dass dort nicht stillschweigend eines der vollständigen Dokumente angezeigt wird.

Einen stabilen Umschalter verwenden, wenn Aushandlung nicht verfügbar ist

Dieses Konzept benötigt eine Auslieferungsschicht, die einen Anfrage-Header lesen und eine Antwort auswählen kann. Die Dokument- und URL-Mechanismen von WHATWG beschreiben Dokumente und Adressen. Ein Attribut lang oder geänderter Linktext allein erzeugt keine HTTP-Aushandlung. Die anfrageabhängige Auswahl gehört in die HTTP-Auslieferungskonfiguration. HTML-Standard, RFC 9110: HTTP-Semantik.

Wenn das Publikationssystem keine solche Auslieferungsfunktion bietet, verwenden Sie eine feste Sprachauswahl auf der Startseite mit direkten Links zu den vollständigen Sprachseiten. So bleibt die Wahl den Lesern überlassen, und Googles Empfehlung zu separaten Sprach-URLs und sichtbaren Sprachumschaltlinks wird befolgt. Hier wird keine Aushandlungsfunktion eines bestimmten Publikationsprodukts vorausgesetzt. Verwaltung multiregionaler und mehrsprachiger Websites.

Das praktische Abnahmekriterium ist einfach: Präferenzen können auf der Startseite helfen, während explizite Sprachlinks zuverlässige Ziele bleiben. Schließen Sie die Arbeit mit einer dokumentierten Ausweichregel, passenden Sprachdeklarationen in den Dokumenten, wechselseitigen Sprachannotationen und anfragenweisen Nachweisen dafür ab, dass der Routing-Vertrag eingehalten wird.

Quellen