What is the best way to detect a browser user's locale in 2012?

Question

I want to detect a user's locale (not their location). The problem is that none of the methods seem reliable.

Accept-Language Header

Pros

1. You're meant to get a list of values which can reveal true locale if the browser has been altered to default to something else.
2. Seems accurate in IE by default?
3. Accurate in IE by default means accurate in FF on Windows by default? (i.e. you download the correct version from mozilla.org)
4. Same as #3 for Opera on Windows?

Cons

1. Server side overhead and interference with caching (or an extra XHR).
2. Defaults to "en-us" in Chrome on all systems for English unless you install your local dictionary and drag it to the top.
3. Not sent by Safari?
4. Incorrect by default in Safari and Chrome mean that http://mozilla.org and http://opera.com direct to the user to the wrong downloads and will also install "en-us" versions of themselves.

Conclusion

• Completely unreliable on OSX since every browser will be wrong by default. However should be accurate in IE and FF on Windows.

window.navigator.language/userLanguage

Pros

1. The best part of this is that it's nice lightweight client side solution.
2. Seems accurate in IE by default?
3. Seems accurate in FF on Windows by default?

Cons

1. Always "en-us" by default in Safari on all systems.
2. Defaults to "en-us" in Chrome on all systems for English unless you install your local dictionary and drag it to the top.
3. Always just "en" in Opera.

Conclusion

• Even more unreliable than Accept-Language.

IP Geolocation

Pros

1. Works independently of browser and OS language settings.

Cons

1. Works independently of browser and OS language settings.
2. All the usual about performance, pricing, keeping it up to date, etc.

Conclusion

• Whether this works really depends on why you're trying to detect a user's locale. This method gives you a user's locality which isn't the same as locale in an i18n sense.

HTML5 Geolocation

Pros

1. Generally as accurate as IP geolocation without the server overhead.

Cons

1. Requires the user to allow you access to their location.
2. Browser support (actually support looks pretty good).

Conclusion

• Having to ask for permission is generally a deal breaker. Also same conclusion as IP geolocation.

Summary

It now seems like detecting a user's locale is harder than ever while detecting their physical location has become easier. The big offender is Safari which should at least reflect the OS settings by default on OSX but Chrome isn't setting any examples either. Even if people install their local dictionary to Chrome I really doubt they will also drag it to the top of the list.

I can't blame Mozilla and Opera for getting dragged down by other browsers misreporting to their download pages. However it would mitigate the problem if they would switch their download pages to use geolocation instead of presumably looking at Accept-Language.

But really, what options are left to detect a user's locale now that IE is no longer dominant? Is there anything left?

Answer 1

This depends on what you mean by “user’s locale”. The possibilities listed in the question reflect different meanings for “user’s locale”. None of them reflects the adequate meaning in modern localization, namely the set of cultural conventions preferred by the user (including a list of human languages in order of preference). The way to find that is to ask the user about them.

Naturally, you should only ask about conventions that really matter in the context, and you may consider storing the preferences, once expressed by the user, in a cookie, in HTML5 storage, in a user database, or somewhere else.

Browsers generally allow the user to specify a list of preferred languages, to be sent in Accept-Language headers. This however relates to a single aspect of locale concept only, it is unknown to most users, and it is known to have incorrect defaults very often.