Automatic User Language Detection in TranslatePress

Redirecting visitors to their own language preference based on browser language or IP address is a feature often requested by our TranslatePress users.

This can be easily achieved using the Automatic User Language Detection add-on.

Below we’ll go through the reasons for using automatic user language detection as well as how it’s implemented in TranslatePress.

Why Automatic User Language Detection matters

First time visitors expect to see the website in a language they understand. With such a short attention span it’s easy to lose users who are not finding the language switcher soon enough. This is why it is important not only to have their language available, but to automatically redirect to it.

The way automatic language detection works is that the last visited language is remembered through a cookie, so returning visitors will always visit your website directly in their chosen language.

How Automatic User Language Detection works in TranslatePress

The Automatic User Language Detection add-on works out-of-the-box, with no required setup steps.

There is no need to register for IP address language services, because the language recognition based on IP happens locally with the help of GeoLite2 databases from MaxMind.

There are two ways of finding out what languages the visitors speak: either by browser language setting or by IP address. In the community, the browser language is seen as the most reliable information, but it depends on who your targeted audience is in order to decide which works best for your website.

If you want to change the default setting of taking into account the browser language first and then IP address, you can do so with a simple select found in Settings -> TranslatePress. You can choose to determine language based solely on IP address or solely on browser language, or a combination between these two.

Automatic Detection of User Language TranslatePress

Hard redirects vs. soft redirects. A technical issue

We chose not to have any hard redirects in place for several reasons. Hard redirects, meaning those that happen on the server side, simply do not work with caching systems, be it a WordPress plugin, or host caching system. The page served from cache would not take into account the correct language for each visitor, since the code on the server never gets executed.

Caching is not the only problem with hard redirects. It also requires users to have their browsers accept cookies and allow JavaScript to run. Otherwise it would not allow users to switch language since it would keep redirecting to the initially detected language.

So how is our add-on solving all of these issues caused by the hard redirects?

The Automatic User Language Detection add-on uses only soft redirects, which happen on the client side. But there’s a problem: finding out the language preference sent by the browsers through the Accept-Language request HTTP header can only be read on the server side. The solution is to make a fast custom ajax request internally to get our needed information, all without using the slow loading WordPress environment.

The browsers that do not accept cookies or prevent JavaScript from running, will still allow users to manually switch to their desired language.

A well-thought-out solution

The final result is a versatile and fast solution, that works extremely well with a wide range of environments seen both on server side and on client side.

See how you can take advantage of the Automatic User Language Detection Add-on and other useful features that TranslatePress offers.

TranslatePress Multilingual

TranslatePress is the easiest way to translate your WordPress site. It's fast, won't slow down your website, works with ANY theme or plugin and it's SEO friendly.

Get the plugin

Related: Multilingual SEO on WordPress – 7 Tips to Rank In All Languages

5 thoughts on “Automatic User Language Detection in TranslatePress

    1. Hi Guillermo,

      First make sure you have the latest version of the add-on.
      If that didn’t fix your issue, try briefly switching your theme with a default WordPress theme. If the issue is gone, check to see if your theme is adding the language attributes in the html tag like this:
      html class="no-js" ... language_attributes();
      You can reach out to our support if the issue persists and I’m sure we’ll get to the bottom of it.

Leave a Reply

Your email address will not be published. Required fields are marked *