Förhandla om språk endast på /, och låt uttryckliga URL:er som /en/ och /fr/ alltid visa det språk som anges i URL:en. Den här guiden visar en Mac-baserad desktoputgivare hur beteendet kan specificeras, hur dokumentlänkar som går att hitta bevaras och hur resultatet testas.

Det genomarbetade exemplet är en syntetisk offentlig dokumentsamling med engelska och franska versioner av en kort guide till att arrangera former. Rotsidan är en språkväljarsida vars inledande text kan anpassas efter förfrågan. Alla exempelsökvägar beskriver ett föreslaget upplägg; de gör inte anspråk på att sidor för närvarande finns på dessa adresser.

Definiera URL-beteendet innan du ändrar språkinställningarna

Börja med ett enkelt routningskontrakt. I det här exemplet hjälper rotsidan läsarna att välja språk, medan de två uttryckliga sökvägarna innehåller det fullständiga översatta dokumentet. Google rekommenderar separata URL:er för språkversioner och avråder från att automatiskt omdirigera läsare mellan versionerna utifrån ett antaget språk. Synliga länkar låter läsarna välja själva. Hantera flerspråkiga webbplatser och webbplatser för flera regioner.

Begärd sökväg Avsett svar Språkpreferensens effekt
/ Språkväljare med en kort introduktion Kan ändra introduktionen och den föreslagna länken
/en/ Fullständigt engelskt dokument Dokumentets språk ändras inte
/fr/ Fullständigt franskt dokument Dokumentets språk ändras inte
En opublicerad sökväg Svar om att sidan saknas Får inte i tysthet bli ett annat dokument

Behandla tabellen som implementationsunderlag. Tillämpa språkval först efter att du kontrollerat om begäran gäller rotsidan. En generell regel som körs före varje sidbegäran kan åsidosätta ett uttryckligt val och bryta mot kontraktet.

En person som till exempel följer /fr/ ska fortfarande få det franska dokumentet även om begäran föredrar engelska. Den engelska preferensen är användbar vid den obestämda ingången; den uttryckliga sökvägen anger redan valet på andra ställen. Den här prioriteringen är designrekommendationen som används i hela artikeln.

Håll båda språklänkarna synliga på varje sida. På rotsidan kan ett föreslaget språk göra det första valet enklare utan att dölja det andra alternativet. I de fullständiga dokumenten ska språkväxlaren leda direkt till motsvarande dokument.

Välj en förutsägbar policy för språk på rotsidan

Accept-Language anger föredragna svarsspråk, med kvalitetsvikter som fr;q=0.9,en;q=0.5. Det kräver inte att en server tillhandahåller alla begärda språk. En kvalitetsvikt på noll betyder att språket inte accepteras. Content-Language beskriver den avsedda målgruppen för den returnerade representationen; den väljer inte en route. RFC 9110: HTTP-semantik, avsnitt 8.5, 12.4.2 och 12.5.4.

Skriv ned vilka språk som stöds och vilken reservlösning som används innan du konfigurerar något. I det här exemplet används engelska och franska introduktioner, med en engelsk introduktion och båda språkalternativen när begäran inte innehåller någon användbar matchning. Den reservlösningen är ett illustrativt publiceringsval, inte ett HTTP-krav.

Använd en språkmatchningsimplementation med en uttrycklig policy. RFC 4647 skiljer mellan filtrering och uppslagning: uppslagning väljer ett resultat, behandlar begärda intervall i prioritetsordning och tar stegvis bort undertaggar när en matchning söks. Den kräver också att applikationer som använder uppslagning definierar sitt standardbeteende. Därför kan en begäran om fr-CA via uppslagning nå en introduktion på det generella stödda språket fr. RFC 4647: Matchning av språktaggar, avsnitt 3.4–3.4.1.

Välj inte språk genom att söka i headern efter den första förekomsten av fr eller en. Den genvägen missar vikter och undantag. Matchningslagret ska tolka preferenser, ta hänsyn till undantag med vikten noll och sedan tillämpa den dokumenterade reservlösningen.

Språkpreferens i begäran till rotsidan Förväntat resultat i det här exemplet
Header saknas Engelsk introduktion med båda alternativen
fr Fransk introduktion med båda alternativen
fr-CA,fr;q=0.9,en;q=0.5 Fransk introduktion
en;q=0.9,fr;q=0.2 Engelsk introduktion
de Reservlösning med språkväljare
fr;q=0,en;q=1 Engelsk introduktion; franska väljs inte
*;q=0 Uttryckligen definierad hantering av omatchat språk

Den sista raden kräver ett medvetet beslut. För den här språkväljardesignen ska du ange att en begäran där alla språk är undantagna får reservlösningen med språkväljare, eftersom applikationen avstår från att följa preferensen, i stället för att hävda att engelska matchade den. Om strikt språkförhandling krävs ska du i stället definiera och testa motsvarande beteende för icke accepterade svar. Oavsett vilket bör du undvika att av misstag behandla noll som en vanlig låg preferens.

Håll dokumentspråk, länkar och sökannoteringar i linje

Ange varje HTML-dokuments lang-attribut till dess faktiska primärspråk: en för den engelska sidan och fr för den franska sidan. WHATWG definierar lang som det primära språket för ett elements innehåll och textbärande attribut, med arv från föräldern när attributet utelämnas. En språkprefix i URL:en gör inte den deklarationen. HTML-standarden: Attributen lang och xml:lang.

Kontrollera navigeringslänkarna liksom sidtexten. Relativa URL:er löses mot en bas-URL enligt WHATWG:s URL-standard. Om inget annat dokumentunderlag används löses exempelvis fr/ från https://example.com/en/ till https://example.com/en/fr/; /fr/ löses till ursprungsadressens franska sökväg. Använd den avsedda absoluta sökvägen i den synliga språkväxlaren. URL-standarden: Att skriva och tolka URL:er.

Sökannoteringar har ett annat syfte. Google stöder annoteringar för motsvarande språkversioner via HTML, HTTP-headers eller en webbplatskarta. Välj en metod som är enkel att hantera. Varje version ska ange sig själv och sina motsvarigheter med fullständiga URL:er, och versionerna ska länka till varandra via dessa annoteringar. Språkväljaren på rotsidan kan vara målet x-default. Informera Google om lokaliserade versioner av din sida.

För den syntetiska samlingen är annoteringsmappningen följande:

Annotering Syntetisk destination
en https://example.com/en/
fr https://example.com/fr/
x-default https://example.com/

Lägg in dessa relationer med publiceringssystemets mekanism för annoteringar. Mappningen är en specifikation, inte körbar markup. x-default konfigurerar inte serverns språkförhandling och tillhandahåller ingen översättning. Google anger också att de fastställer sidans språk algoritmiskt, inte genom att använda hreflang eller HTML lang för att identifiera det. Informera Google om lokaliserade versioner av din sida.

Se till att de fullständiga översättningarna går att nå oberoende av rotsidans anpassning. Google uppger att deras sökrobot skickar begäranden utan Accept-Language och varnar för att lokalanpassade sidor kan göra att vissa varianter inte upptäcks. En tillförlitlig reservlösning och direkta språk-URL:er löser upptäcktsproblemet utan att sökroboten behöver begära olika introduktioner på rotsidan. Så genomsöker Google lokalanpassade sidor.

Se till att cachade svar från rotsidan respekterar språkvalet

När språkvalet på rotsidan beror på Accept-Language ska du inkludera Vary: Accept-Language i svaren från rotsidan, även i reservsvaret. Behåll eventuella befintliga varieringsfält. Ett illustrativt franskt svar från rotsidan skulle innehålla följande headerfragment; det är inte ett fullständigt HTTP-meddelande: RFC 9110: HTTP-semantik, avsnitt 12.5.5.

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

RFC 9111 kräver att en cache matchar de begärandefält som anges av Vary innan ett lagrat svar återanvänds utan omvalidering. Det här är viktigt eftersom URL:en till rotsidan förblir densamma medan introduktionen ändras. Vary beskriver vilka indata som styr valet; den implementerar inte språkmatcharen. RFC 9111: HTTP-cachning, avsnitt 4.1.

För /en/ och /fr/ varierar dokumentet enligt den här designen inte med Accept-Language. Kontrollera hela leveranskedjan, inklusive eventuella delade cachar, mot routningskontraktet. Som praktisk felsökningsmetod kan du växla mellan engelska och franska begäranden till rotsidan och sedan vända på ordningen. Om rotsidan upprepade gånger visar det tidigare begärda språket bör du undersöka cachebeteendet och routningen tillsammans.

Testa kontraktet från en Mac

Förbered först de tre syntetiska sidorna på en offentlig demonstrationsadress. Testet nedan kräver att den adressen bara innehåller demonstrationssamlingen på /, /en/ och /fr/. Testet skapar inte sidor och konfigurerar inte en värd. De illustrativa example.com-adresserna ovan är inte en fungerande testinstallation.

Öppna appen Terminal på Mac-datorn och kör curl --version för att bekräfta att curl är tillgängligt. Klistra sedan in hela följande skalskript för diagnostik. När du uppmanas till det anger du demonstrationsadressen, inklusive https://, utan sökväg eller avslutande snedstreck.

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

Diagnostiken skriver ut svarsrubriker och svarstext. Curls --header anger preferensen; ett tomt värde tar bort den headern. --dump-header - skriver ut headers till standardutdata, och tidsgränserna begränsar varje överföring. Omdirigeringar följs avsiktligt inte, så en oväntad omdirigering förblir synlig. curl — Så använder du curl.

Skalskriptets syntax har kontrollerats; inget påstående görs om en demonstrationsdriftsättning eller ett fungerande språkresultat i en live-miljö. Skriptet avbryts om en curl-överföring misslyckas, men ett HTTP-felsvar kan ändå visas i utdata och måste granskas.

Jämför svaren från rotsidan med preferenstabellen. Kontrollera sedan att varje svar från /en/ innehåller engelsk text och att varje svar från /fr/ innehåller fransk text, oavsett den angivna preferensen. Kontrollera statuskoder, oväntade Location-fält, språkdeklarationen i svaret och den faktiska dokumenttexten. En korrekt header med fel innehåll är fortfarande ett misslyckat resultat.

Öppna slutligen båda uttryckliga URL:erna i en webbläsare. Följ varje språkväxlare, läs in målsidan igen och kontrollera adressfältet. Det fångar navigeringsfel som en lyckad direktbegäran inte skulle avslöja. Testa en opublicerad sökväg separat och bekräfta att den inte i tysthet visar något av de fullständiga dokumenten.

Använd en stabil språkväljare när språkförhandling inte är tillgänglig

Den här designen kräver ett serveringslager som kan läsa en begärandeheader och välja ett svar. WHATWG:s mekanismer för dokumentspråk och URL:er beskriver dokument och adresser; att lägga till ett lang-attribut eller ändra länktext skapar inte i sig HTTP-språkförhandling. Det begärandeberoende valet hör hemma i HTTP-leveranskonfigurationen. HTML-standarden, RFC 9110: HTTP-semantik.

Om publiceringssystemet saknar sådan serveringsfunktion använder du en fast språkväljare på rotsidan med direkta länkar till de fullständiga språksidorna. Då kan läsaren fortfarande välja själv, i linje med Googles rekommendation om separata språk-URL:er och synliga språkväxlarlänkar. Ingen språkförhandlingsfunktion hos någon specifik publiceringsprodukt förutsätts här. Hantera flerspråkiga webbplatser och webbplatser för flera regioner.

Det praktiska godkännandekriteriet är enkelt: preferenser kan hjälpa på rotsidan, medan uttryckliga språklänkar förblir tillförlitliga destinationer. Avsluta med en dokumenterad reservlösning, matchande språkdeklarationer i dokumenten, ömsesidiga språkannoteringar och belägg från enskilda begäranden som visar att routningskontraktet håller.

Källor