Delivering multi-lingual content in the best language for your website visitors
Historically, websites have used a visitor’s IP address to ‘guess’ where they live and suggest the most appropriate language. This is referred to as ‘geo-IP lookup’, and this approach is still the most common way that websites serve multilingual content. However, there is a much better way…
For those unaware, an IP address is a unique number assigned to your home’s internet connection. It looks something like this:
As a general rule, every household and business has a different IP address, but the first few numbers will usually be the same as other premises who buy their broadband from the same Internet Service Provider (think Comcast, BT, Time Warner), in the same region. We can say that these people belong to the same ‘IP range’.
Various companies, including many content management system developers, build lists of IP addresses along with the country each is located within. As you can imagine, this a pretty huge task. This list is shared with your website’s content management system, usually at a cost. When a visitor comes to your website, your CMS checks to see if the visitor’s IP address is within one of the known ranges and serves the web page in the corresponding language.
Perfect, right? Well, no…
What’s the problem with GEO-IP language suggestion?
Actually, there are a whole bunch of problems with Geo-IP based language suggestion. Most problems with Geo-IP stem from making assumptions about a user’s language preference based upon inaccurate lists. A good list is at best 90% accurate, and that is in my experience an optimistic estimation. We’ll touch briefly on why this is the case, and how this could impact your website visitors.
- Sometimes a list owner will never work out where an IP address is located, meaning the default language will be served to the user.
- Internet Service Providers mostly use ‘dynamic DNS’. This involves frequent changes to their customers’ IP addresses; an IP address that is in one country on Tuesday could be in another country on Wednesday, meaning the user could be served the wrong language in error. It could be weeks or even months before the list owner figures out where a new IP address is located, or notices an existing one has moved.
- People who live near a country border may share an IP range with people on the other side of the border, meaning one group could be served content in the wrong language.
- Just because a user is in a specific country does not mean they wish to browse the internet int hat language. If an un-cultured Englishman such as myself is travelling to Germany on a business trip, Geo-IP will serve me every website in German for the duration of my trip, which is very frustrating.
- Many businesses route all of their traffic through datacenters using either a Virtual Private Network (VPN) or proxy. In the case of our organisation, the corporate VPN directs all traffic through a datacentre in New Jersey, US. This results in our entire global organisation constantly seeing American versions of every website. Whilst having to convert timezones to GMT and dollars to pounds is a minor irritation, I imagine it is hugely more frustrating for our colleagues from non-English-speaking countries who share the same datacenter. I can’t count the amount of times I have explained to confused executives why they are unable to see the German version of our website from a German location.
“Most problems with Geo-IP stem from making assumptions about a user’s language preference based upon inaccurate lists.”
What’s the best way to detect a user’s language preference?
Your users have already told you what language they like – you just haven’t been paying attention! When you set up your computer and/or browser, you probably chose your preferred language from a list. This does more than just changing the language of your operating system; your browser announces this preference to each web server as you navigate around the internet. For developers, you can get a user’s code using this snippet:
var userLang = navigator.language || navigator.userLanguage; alert ("The language is: " + userLang);
This is passed in the form of a four-letter code that looks a little like this:
Actually, this is two 2-letter codes stuck together. The first part is the ISO code for language and the second part is for the country. In the example above, this is telling the browser that my preferred language is the British (GB) varient of English (en). This is useful if you want to serve local versions of the same language (eg. one version of the Spanish page for users in Spain and a different version for Mexico, who speak with a different dialect). However, if your site doesn’t need to be that specific, you can detect and serve language content based only on the first part of this code.
Language suggestion and User Experience
Our aim as UX designers is to make the experience as convenient as possible for visitors, whilst respecting their choices. Attempting to be too clever and making assumptions on behalf of the user can easily backfire. Whilst this method should be more accurate than Geo-IP detection, there are still scenarios where the user may want to choose their own language. For example: if a user has come to your website via a search engine looking for a specific piece of content, it would be very frustrating for them to be redirected automatically to a page in a different language which may not contain the content they are expecting.
Taking this control away from the user is likely frustrating for them and is considered bad practice. The approach I’d suggest in this case is:
Suggest, don’t assume
Rather than assuming a user wants to switch language, simply make a suggestion. This empowers the user by giving them the choice.
At element.com, when we detect a user’s browser language does not match the language of the page they are viewing, we present them with a modal (popup) offering the choice to switch. Remember to keep the message very simple as the user may not speak the language in the options. Once the user has expressed a preference, the website remembers their choice and will not bother them again.
It’s easy to get caught up trying to be smart, but there is nothing more frustrating than a one-way street on the internet. Maybe the user didn’t find what they were looking for on the suggested language version, or maybe they’re happy viewing other parts of your site in the original language. For this reason, it’s always important to include manual language-switching controls. These are traditionally located in the footer of the site, but increasingly we’re seeing them in a prominet position right in the header. This is a great choice if your customer base is spread across multiple countries.
There are a tonne of great resources out there to help you design your language switcher but here are some quick UX tips:
- Avoid the use of flags as your language icons as countries do not always represent languages and vice-versa. Think of the Spain vs Mexico example cited earlier in this article.
- Descriptive text-links using local spelling or language codes are easily recognisable.
Our visitors have already told us their language preference. All we have to do is listen to them by reading the ISO codes shared by the browser. With some clever UI design, we can ensure that our users are always presented with the best possible option without leaving them feeling disempowered and frustrated.
This is not the default approach offered by most website content management systems, and is not difficult to implement, but will likely require some bespoke development. Be warned that your software vendor may discourage you from switching as the geo-IP lookup is often a nice revenue stream for them (looking at you, SiteCore). However, it is important that usability should dictate functionality and not the other way around, so it is definitely worth persevering.
Whilst you’re at it, don’t forget HREFLANG meta tags on your page so that the SEO goodness is shared between language versions and international search-engines know to index the right variants of your pages.