If You’re Using Geo-location to Change Language, You’re Doing it Wrong

There are use cases for geo-location based on the client’s IP address: suggesting nearby attractions; plotting routes from the current location to a specific destination; getting weather/tidal/astronomical information; and so on. Geo-location by IP address is not perfectly accurate, but it’s close, certainly close enough to service these examples.¹

One thing that we should not use geo-location for is determining the language of the content. Why?

1. The client might be connecting through a VPN or proxy, in a location far away from that of the intermediary;
2. The clients IP address might be otherwise disguised.

You must also consider the international traveller? I only read English, if I’m abroad web-servers that use geo-location to determine language are going to supply me with content I can’t read.

I use the Internet almost exclusively via a VPN (a selection of them in fact). The software I use to manage this is IPVanish which chooses which server to route my traffic through based on the latency of my connection to that server (opting for the lowest latency first). I am physically located in the UK, so IPVanish often routes through servers in France, Holland and Germany. This is great, until I use certain websites, which then give me content in French, Dutch or German!²

This is not good behaviour. There is already an established mechanism for the client to specify her preferred language(s) to which the web-server should respond accordingly. It’s called Content Negotiation and RFC 7231 provides a detailed definition of it. In essence, it describes a system whereby the client browser sends an Accept-Language header, the server can then use this to determine the language of the content it returns.

Before I sat down to write this, I did some Googling around “content negotiation” and “Accept-Language” in an attempt to determine why web-server administrators might choose to use geo-location over content negotiation. The only argument against content negotiation that I found was that clients might not have their local system set to the correct language.

Wait… what? That can’t be right, surely? If the client has her machine set to the wrong language, then her whole UI is going to use that language. This isn’t necessarily a problem if she sets her language to en-us when the she really wants en-gb. It would certainly be a problem if she sets the language to fr - meaning our English-speaking user has her UI and her web-pages in French! How likely is it that the user would have the language on her local system set to one she couldn’t understand? The “incorrect client setting” argument looks like a straw man to me.

Don’t use geo-location to determine language. Use it to determine location. If you need to ascertain what language to deliver your web-content in, use the Accept-Language header. That’s what it’s there for.

In an ideal world, if you have multi-language content, choose the default language based on the Accept-Language header and provide a UI element that allows the user to change the language. If the user makes an alternative selection, remember that preference for her future visits.

It’s not rocket science.