How to handle language detection and suggestion?

Question

In a website that offers translated versions of the website in various languages (6), how should we handle language detection and suggestion?

My theory is that:

• Users hate splash screens in which you have to choose a language before you arrive at the website/page.
• Users may arrive at the English version of a page, while they would prefer a different language.
• Users like to be in control of the language version of a website, and do not expect to see a Korean version of a page, if they clicked an English page link in Google Search results while browsing from South Korea. The Korean version of the page would not match expectations of the page link, title and description that were in English.

My solution is:

• Do not use splash screens

• Do not auto-change language based on geo location when a user arrives at a page.

• Offer a non-obtrusive way of notifying the user of a possible preferred language:
  Scenario:
  A user from South Korea arrives on English page of the website that also offers a Korean translation. Determine user's geo location and if country of visit does not match the active language and the language of the country of visit is available; offer a message (overlay pop-up, cookie-like bar at the top or bottom?) that notifies the user of the available language and offer to switch.

Is this a good practice or are there more user friendly solutions?

Answer 1

There is an Accept-language HTTP field sent to your web server with every user request. This field is controlled by the browser, and nowadays is very accurate at describing user's language preferences. The only time it wouldn't work could be if someone accessed your website from a public computer: for example from a library or internet cafe. For those users you should have an explicit language selector. Check these questions:

• Where should the language selector be located?
• How should it look like?

Answer 2

There are two scenarios:

1. The request contains a language identifier. This will happen on search result pages as well as on external links. Then use that language.

2. The request does not contain a language identifier. Then use the HTTP Accept-Language header to determine, which language to choose.

This procedure will meet the user's expectation. Nevertheless, a language selector should be provided, so the user can switch to a language, (s)he is more comfortable with.

Answer 3

I think your approach is the correct one. Now, I have troubles with some customers that don't see the message that suggests their language and they end up thinking the website is from another country or they just leave. I have to say that this mainly happens when they browse with their phone and since the site is not mobile friendly—just yet—the suggestion bar at the button goes untoniced. For this reason I'm considering the splash screen even thought it annoys me personally as a user.

One thing I'd add to your theory is to automatically load some information based on the guessed location. I do this for the phone number and shipping country displayed at the header so the customer feels like he's browsing a local business—you can have multiple VoIP public phones and scale to a multinacional business cheaply.

Answer 4

This has been a struggle for me for many years. If I have 5 languages on the site and I am 'guessing' language from visitor settings or preferences, not URL , I will end up with one URL like https://example.com/pages/about-us - and content available in 5 different languages. This will not be index-able and offer-able by Google search engines correctly.

At the end, Google guidelines itself helped me to solve and define rules, how I am setting user language.

Google recommends that any given URL should have unique and the same content:

Google: Use different URLs for different language versions.

So, language setting 'should' appear in a link and link language should and must be used as main priority (clicking in Google search results on the link must go directly to correct language without any redirections).

All consequential requests (DOM, static files, JSON, ajax .etc) can ignore language in link and use 'remembered' logic below:

1. Read from URL
   • must have "fallback". What if it's accessing non existing files, like developers main.css.map - without language code in URL ? It will 'reset' session language;
2. Read from Cookie, if is previously set;
3. Read from Session, if is previously set;
4. Try to detect from browser (using correct codes and priority format https://stackoverflow.com/a/2316527/1720476);
5. If nothing succeeds OR, detected language is not in available languages - we'll set default language;
6. As last step - save (or cache) language in Cookie or Session to be used for next requests.