Hey there.
Server based language detection has some drawbacks. No matter if you stick to the accept-language header or GeoIP or whatever. And especially using GeoIP is completely the wrong tool since a country is not a language but a country
So to me, picking languages is completely a client issue. Let me explain why.
Think about every bot or crawler hitting your site. Let’s call it googlebot, just as an example. Using a server based mechanism to either switch the language of your result content or create a redirect to a URL fitting this language better, both will prevent googlebot from reaching other content than the english one.
The most reliable way and least annoying one is leaving this decission to the user.
Here’s what we usually do:
- Every language variant gets its own URL.
- There’s the
link rel=alternate
tag. Make use of it and expos every language variant of your site. - Changing languages is done by the user by clicking a button or a link. Neither on the server side nor on the client side, nothing is done automatically.
- Once the user decided for a language, its value is stored in a cookie. That’s completely client side and done by “onclick”.
- If this cookie is not available, cient side JS code compares the browsers
accept-header
with all availablelink refl=alternate
variants and shows a pretty prominent link to the user asking to either switching the language immediately (which will set the cookie to the target language of the link since its an explicit klick on a button) or keept the current language (which will set the cookie to the current language because that’s a button, too). - If this cookie is available, client side JS code compares not the browsers
accept-header
but the cookie value with all availablelink rel=alternate
variants.
This results in:
- As long as the page language delivered to the user fits the
accept-language
header, the user is not distrubed. - If a user has decided for a language (which means there is a cookie value available) that fits the current language, the user is not disturbed, too.
- If the user has not decided for a language, yet (which means there is no cookie avilable) and the browsers
accept-language
votes for a language switch, a promiment button is displayed. - If a user has dedied for a language that is not the one currently displayed and there is a better alternative, the button is shown as well.
There is only one tiny limitation of this setting: The browsers accept-language
header is not available to JS, unfortunately. There is the current browser language, which is the language of the browser UI. But that’s not the accept-language
.
So I created a small PHP script that just fetches the accept-language
from the request header and returns it.
Here is a live example of this:
https://www.netzsch.com/ko/
Of course that’s a TYPO3 CMS page and no Neos page, but there is really no server side code involved, except one tiny script that looks something like this <?PHP echo $_SERVER['HTTP_ACCEPT_HEADER'];
and has nothing to do with any framework.
Regards,
Stephan.