Skip to main content
De web-service kiest de taal van de interface op basis van de onderstaande instellingen, per verzoek aan de hand van de hostnaam die de browser gebruikte. De talen en de instellingen staan beschreven in Lokalisatie.

Eén taal

Meerdere talen op subdomeinen

1

Routeer elke taalhost naar Ayakaleaf Pro

Voeg per taal een DNS-naam toe en routeer ze allemaal naar Ayakaleaf Pro met een certificaat dat ze allemaal dekt, bijvoorbeeld *.example.com. Je ingress of load balancer moet de Host-header ongewijzigd doorgeven, wat ingress-nginx en HAProxy standaard doen.Gebruikers moeten de taalhosts op de standaardpoorten bereiken (https://cn.example.com, niet https://cn.example.com:30443): Ayakaleaf Pro vergelijkt de host zonder de poort.
2

ConfigMap

30-config.yaml (additions)
Met COOKIE_DOMAIN werkt de inlogcookie op elke taalhost. Zet de JSON tussen enkele aanhalingstekens. Ongeldige JSON in OVERLEAF_LANG_DOMAIN_MAPPING stopt elke service van de pod bij het opstarten, dus controleer kubectl -n overleaf get pod na de herstart.

Meerdere replica’s

De taal komt uit de hostnaam van elk verzoek, dus die hangt niet af van de replica. De sticky cookie van de load balancer wordt per hostnaam ingesteld, tenzij je er een domein aan geeft, dus van taal wisselen kan een gebruiker naar een andere replica verplaatsen; de sessie staat in Redis en blijft geldig.

Getest op Kubernetes

Op Kubernetes 1.37 achter HAProxy, met OVERLEAF_LANG_DOMAIN_MAPPING die de host van de site koppelde aan Engels, een de.-host aan Duits en een fr.-host met de NodePort :30081 aan Frans: de host van de site toonde Engels, de de.-host Duits, en de fr.-host met de poort viel terug op Engels, zoals hierboven beschreven.
Laatst gewijzigd op 2 november 2026