Onderhandel alleen op / over de taal en laat expliciete URL’s zoals /en/ en /fr/ altijd de taal leveren die ze benoemen. Deze gids laat een uitgever op een Mac-desktop zien hoe die dit gedrag instelt, vindbare documentlinks behoudt en het resultaat test.
Het uitgewerkte voorbeeld is een synthetische openbare documentverzameling met Engelse en Franse versies van een korte gids over het rangschikken van vormen. De hoofdmap is een taalselectiepagina waarvan de inleidende tekst zich aan het verzoek kan aanpassen. Alle voorbeeldadressen beschrijven een voorgestelde inrichting; ze zijn geen beweringen over pagina’s die momenteel op die adressen worden gehost.
Bepaal het URL-gedrag voordat je de taalinstellingen wijzigt
Begin met een klein routeringscontract. In dit voorbeeld helpt de hoofdmap lezers een taal te kiezen, terwijl de twee expliciete paden het volledige vertaalde document bevatten. Google raadt afzonderlijke URL’s voor taalversies aan en adviseert lezers niet automatisch tussen die versies om te leiden op basis van een veronderstelde taal. Zichtbare links laten lezers zelf kiezen. Sites met meerdere regio’s en talen beheren.
| Opgevraagd pad | Beoogde reactie | Effect van taalvoorkeur |
|---|---|---|
/ |
Taalselector met een korte inleiding | De inleiding en voorgestelde link kunnen veranderen |
/en/ |
Volledig Engels document | De taal van het document verandert niet |
/fr/ |
Volledig Frans document | De taal van het document verandert niet |
| Een niet-gepubliceerd pad | Reactie voor een ontbrekende pagina | Mag niet stilzwijgend een ander document worden |
Beschouw deze tabel als de implementatieopdracht. Pas taalselectie alleen toe nadat je hebt gecontroleerd of het verzoek de hoofdmap betreft. Een algemene regel die vóór elk paginaverzoek wordt uitgevoerd, kan een expliciete keuze overschrijven en het contract schenden.
Iemand die bijvoorbeeld /fr/ volgt, moet nog steeds het Franse document krijgen wanneer het verzoek de voorkeur geeft aan Engels. De Engelse voorkeur is nuttig bij het onbesliste instappunt; het expliciete pad legt de keuze elders al vast. Deze prioriteitsvolgorde is de ontwerpaanbeveling die in dit artikel wordt gevolgd.
Houd beide taallinks op elke pagina zichtbaar. Op de hoofdmap kan een voorgestelde taal de eerste keuze vergemakkelijken zonder de andere optie te verbergen. Op de volledige documenten moet de taalschakelaar rechtstreeks naar het overeenkomstige document leiden.
Kies een voorspelbaar beleid voor de taal van de hoofdmap
Accept-Language geeft voorkeurstalen voor reacties aan, met kwaliteitsgewichten zoals fr;q=0.9,en;q=0.5. Het verplicht een server niet om elke gevraagde taal aan te bieden. Een kwaliteitswaarde van nul betekent onaanvaardbaar. Content-Language beschrijft de beoogde doelgroep van de geretourneerde representatie; het selecteert geen route. RFC 9110: HTTP-semantiek, secties 8.5, 12.4.2 en 12.5.4.
Leg de ondersteunde talen en de terugvaloptie vast voordat je iets configureert. Gebruik voor dit voorbeeld Engelse en Franse inleidingen, met een Engelse inleiding en beide taalkeuzes wanneer het verzoek geen bruikbare overeenkomst oplevert. Die terugvaloptie is een illustratieve publicatiekeuze, geen HTTP-vereiste.
Gebruik een implementatie voor taalovereenkomsten met een expliciet beleid. RFC 4647 maakt onderscheid tussen filtering en lookup: lookup kiest één resultaat, behandelt gevraagde bereiken in volgorde van prioriteit en verwijdert geleidelijk subtags tijdens het zoeken naar een overeenkomst. Ook vereist RFC 4647 dat toepassingen die lookup gebruiken hun standaardgedrag definiëren. Zo kan een verzoek voor fr-CA via lookup uitkomen bij een ondersteunde algemene fr-inleiding. RFC 4647: Overeenkomsten tussen taaltags, secties 3.4–3.4.1.
Selecteer een taal niet door de header te doorzoeken op de eerste vermelding van fr of en. Die kortere aanpak houdt geen rekening met gewichten en uitsluitingen. De overeenkomstlaag moet voorkeuren parseren, uitsluitingen met gewicht nul verwerken en vervolgens de vastgelegde terugvaloptie toepassen.
| Voorkeur in het verzoek voor de hoofdmap | Verwacht resultaat in dit voorbeeld |
|---|---|
| Header ontbreekt | Engelse inleiding met beide keuzes |
fr |
Franse inleiding met beide keuzes |
fr-CA,fr;q=0.9,en;q=0.5 |
Franse inleiding |
en;q=0.9,fr;q=0.2 |
Engelse inleiding |
de |
Terugvalselector |
fr;q=0,en;q=1 |
Engelse inleiding; Frans wordt niet geselecteerd |
*;q=0 |
Expliciet gedefinieerde afhandeling van niet-overeenkomende talen |
Voor de laatste rij is een bewuste keuze nodig. Geef voor dit ontwerp met een selector aan dat een verzoek waarbij alle talen zijn uitgesloten de terugvalselector krijgt, omdat de toepassing die voorkeur niet honoreert; beweer niet dat Engels ermee overeenkwam. Als strikte onderhandeling vereist is, definieer en test dan het bijbehorende gedrag voor onaanvaardbare verzoeken. Voorkom in beide gevallen dat nul per ongeluk als een gewone lage voorkeur wordt behandeld.
Houd de documenttaal, links en zoekmachineannotaties op elkaar afgestemd
Stel voor elk HTML-document het kenmerk lang van het document in op de werkelijke primaire taal: en voor de Engelse pagina en fr voor de Franse pagina. WHATWG definieert lang als de primaire taal van de inhoud van een element en de tekstdragende attributen ervan, met overerving van de bovenliggende pagina wanneer het kenmerk ontbreekt. Alleen een taalvoorvoegsel voert deze declaratie niet uit. HTML-standaard: De kenmerken lang en xml:lang.
Controleer zowel de navigatielinks als de paginatekst. Relatieve URL’s worden volgens de WHATWG URL-standaard opgelost ten opzichte van een basis-URL. Bijvoorbeeld: zonder een afwijkende documentbasis wordt fr/ vanaf https://example.com/en/ opgelost als https://example.com/en/fr/; /fr/ wordt opgelost als het Franse pad van de origin. Gebruik voor de zichtbare taalschakelaar het beoogde absolute pad. URL-standaard: URL’s schrijven en parseren.
Zoekmachineannotaties hebben een ander doel. Google ondersteunt annotaties voor gelijkwaardige taalversies via HTML, HTTP-headers of een sitemap. Kies één beheersbare methode. Elke versie moet zichzelf en de overeenkomstige versies met volledig gekwalificeerde URL’s aanduiden, en de versies moeten via die annotaties naar elkaar terugverwijzen. De hoofdmapselector kan de bestemming x-default zijn. Vertel Google over gelokaliseerde versies van je pagina.
Voor de synthetische verzameling is de annotatiekoppeling als volgt:
| Annotatie | Synthetische bestemming |
|---|---|
en |
https://example.com/en/ |
fr |
https://example.com/fr/ |
x-default |
https://example.com/ |
Voer deze relaties in via de ondersteunde annotatiemethode van het publicatiesysteem. De koppeling is een specificatie, geen uitvoerbare markup. x-default configureert geen serveronderhandeling en levert geen vertaling. Google vermeldt ook dat het de taal van pagina’s algoritmisch bepaalt, en niet hreflang of HTML lang gebruikt om die te detecteren. Vertel Google over gelokaliseerde versies van je pagina.
Houd de volledige vertalingen onafhankelijk van de aanpassing van de hoofdmap toegankelijk. Google vermeldt dat zijn crawler verzoeken verstuurt zonder Accept-Language en waarschuwt dat locale-adaptieve pagina’s sommige varianten onvindbaar kunnen maken. Een betrouwbare terugvaloptie en rechtstreekse taal-URL’s lossen dat vindbaarheidsprobleem op zonder dat een crawler verschillende inleidingen van de hoofdmap hoeft op te vragen. Hoe Google locale-adaptieve pagina’s crawlt.
Zorg dat gecachete reacties op de hoofdmap de taalkeuze respecteren
Wanneer de selectie op de hoofdmap afhangt van Accept-Language, neem dan Vary: Accept-Language op in de reacties op de hoofdmap, inclusief de terugvalreactie. Behoud eventuele bestaande variatievelden. Een illustratieve Franse reactie op de hoofdmap bevat het volgende headerfragment; het is geen volledig HTTP-bericht: RFC 9110: HTTP-semantiek, sectie 12.5.5.
Content-Type: text/html; charset=utf-8
Content-Language: fr
Vary: Accept-Language
RFC 9111 vereist dat een cache de verzoekvelden controleert die onder Vary zijn genoemd, voordat die een opgeslagen reactie zonder hervalidatie opnieuw gebruikt. Dit is van belang omdat de URL van de hoofdmap gelijk blijft terwijl de inleiding verandert. Vary beschrijft de selectie-invoer; het implementeert de taalherkenner niet. RFC 9111: HTTP-caching, sectie 4.1.
Dit ontwerp varieert het document op /en/ en /fr/ niet op basis van Accept-Language. Controleer het volledige leveringspad, inclusief eventuele gedeelde cache, aan de hand van het routeringscontract. Als praktische diagnose kun je afwisselend Engelse en Franse verzoeken voor de hoofdmap versturen en daarna de volgorde omkeren. Als de hoofdmap steeds de eerder opgevraagde taal teruggeeft, moet je het cachegedrag en de routering samen inspecteren.
Test het contract vanaf een Mac
Zet eerst de drie synthetische pagina’s op een openbare demonstratie-origin. De onderstaande test vereist dat die origin alleen de demonstratieverzameling bevat op /, /en/ en /fr/. De test maakt geen pagina’s aan en configureert geen host. De bovenstaande illustratieve adressen example.com vormen geen werkende testinstallatie.
Open de app Terminal op de Mac en voer curl --version uit om te bevestigen dat curl beschikbaar is. Plak daarna de volgende volledige shell-diagnose. Voer op verzoek de demonstratie-origin in, inclusief https://, zonder pad of afsluitende schuine streep.
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
Deze diagnose toont reactieheaders en -inhoud. Curl’s --header geeft de voorkeur op; met een lege waarde wordt die header verwijderd. --dump-header - toont de headers op standaarduitvoer en de tijdslimieten begrenzen elke overdracht. Het volgen van omleidingen is bewust achterwege gelaten, zodat een onverwachte omleiding zichtbaar blijft. curl — Zo gebruik je het.
De shellsyntaxis van het script is gecontroleerd; er wordt hier geen demonstratie-implementatie of live resultaat van taalroutering geclaimd. Het script stopt als een curl-overdracht mislukt, maar een HTTP-foutreactie kan nog steeds in de uitvoer verschijnen en moet worden gecontroleerd.
Vergelijk de reacties van de hoofdmap met de voorkeurentabel. Controleer vervolgens elke reactie van /en/ op Engelse inhoud en elke reactie van /fr/ op Franse inhoud, ongeacht de opgegeven voorkeur. Controleer statuscodes, onverwachte Location-velden, de taalverklaring in de reactie en de daadwerkelijke documenttekst. Een correcte header met de verkeerde inhoud is nog steeds een mislukt resultaat.
Open tot slot beide expliciete URL’s in een browser. Volg elke taalschakelaar, laad de bestemming opnieuw en controleer de adresbalk. Zo spoor je navigatiefouten op die een geslaagd rechtstreeks verzoek niet aan het licht zou brengen. Test een niet-gepubliceerd pad afzonderlijk en bevestig dat het niet stilzwijgend een van de volledige documenten weergeeft.
Gebruik een stabiele selector als onderhandeling niet beschikbaar is
Dit ontwerp vereist een leveringslaag die een verzoekheader kan lezen en een reactie kan kiezen. De documenttaal- en URL-mechanismen van WHATWG beschrijven documenten en adressen; een kenmerk lang toevoegen of linktekst wijzigen, brengt op zichzelf geen HTTP-onderhandeling tot stand. De verzoekafhankelijke selectie hoort thuis in de configuratie van HTTP-levering. HTML-standaard, RFC 9110: HTTP-semantiek.
Als het publicatiesysteem zo’n leveringsmogelijkheid niet biedt, gebruik dan een vaste selector op de hoofdmap met rechtstreekse links naar de volledige taalpagina’s. Zo behouden lezers de mogelijkheid om te kiezen en volg je Googles aanbeveling voor afzonderlijke taal-URL’s en zichtbare taalschakellinks. Er wordt hier geen onderhandelingsfunctie van een specifiek publicatieproduct verondersteld. Sites met meerdere regio’s en talen beheren.
Het praktische acceptatiecriterium is eenvoudig: voorkeuren mogen helpen op de hoofdmap, terwijl expliciete taallinks betrouwbare bestemmingen blijven. Rond af met een vastgelegde terugvaloptie, overeenkomende taaldeclaraties in documenten, wederzijdse taalannotaties en bewijs per verzoek dat het routeringscontract wordt nageleefd.
Bronnen
- RFC 9110: HTTP-semantiek — IETF / RFC Editor.
- RFC 9111: HTTP-caching — IETF / RFC Editor.
- RFC 4647: Overeenkomsten tussen taaltags — IETF / RFC Editor.
- HTML-standaard — WHATWG.
- URL-standaard — WHATWG.
- Sites met meerdere regio’s en talen beheren — Google Search Central.
- Vertel Google over gelokaliseerde versies van je pagina — Google Search Central.
- Hoe Google locale-adaptieve pagina’s crawlt — Google Search Central.
- curl — Zo gebruik je het — curl.