> For example, your browser's language is set to English. Cool. But, are you in America or somewhere else? Oh you're in Canada, no problem neighbour. Spanish? Are you in Mexico or Spain? Don't worry, I'll give you the appropriate version of our Spanish translations then. French? You in Canada or France? Portuguese, Brazil or Portugal?
This is so utterly wrong and user unfriendly. Let's say that I'm an Australian traveling in Trinidad and Tobago. Somehow your web server has decided that my language is simply "English" (although it certainly is more specific than that) and makes a wild guess that because I'm in Trinidad, I want to read your website in Trinidad English creole...it's a wholly invalid assumption based on the flawed notion that my location somehow reflects my language preference.
Luckily, HTTP 1.1 has Accept-Language standardized, and unlike the solution you present it was designed with the existence of travel in mind. The locale identifiers may already specify a regional variation. My browser sends "en-AU" and your server will have all the information it needs to respond in kind without resorting to a guessing game. It's not only better for me; it's also easier for you, so why over-complicate things and break user expectations?
> Not to mention, when you're operating in a lot of languages,
... an entirely orthogonal issue may occur. Understood, but has nothing to do with location based content delivery and thus does not justify it. Again, though, Accept-Language may prioritize several language and you can use that information to decide which translation to use as a fallback.
> For example, your browser's language is set to English. Cool. But, are you in America or somewhere else? Oh you're in Canada, no problem neighbour. Spanish? Are you in Mexico or Spain? Don't worry, I'll give you the appropriate version of our Spanish translations then. French? You in Canada or France? Portuguese, Brazil or Portugal?
This is so utterly wrong and user unfriendly. Let's say that I'm an Australian traveling in Trinidad and Tobago. Somehow your web server has decided that my language is simply "English" (although it certainly is more specific than that) and makes a wild guess that because I'm in Trinidad, I want to read your website in Trinidad English creole...it's a wholly invalid assumption based on the flawed notion that my location somehow reflects my language preference.
Luckily, HTTP 1.1 has Accept-Language standardized, and unlike the solution you present it was designed with the existence of travel in mind. The locale identifiers may already specify a regional variation. My browser sends "en-AU" and your server will have all the information it needs to respond in kind without resorting to a guessing game. It's not only better for me; it's also easier for you, so why over-complicate things and break user expectations?
> Not to mention, when you're operating in a lot of languages,
... an entirely orthogonal issue may occur. Understood, but has nothing to do with location based content delivery and thus does not justify it. Again, though, Accept-Language may prioritize several language and you can use that information to decide which translation to use as a fallback.