6 ms·

Agreed, location should not be the primary way to decide which language is served up, but it's also not as simple as the article suggests. I have been building

Agreed, location should not be the primary way to decide which language is served up, but it's also not as simple as the article suggests. I have been building web apps for a couple decades and have some that operate in dozens of languages. My best practise is to only look at your region when your selected language has regional variations. However, that's true for most of the popular languages which is why it isn't as easy as the article suggests. 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? Not to mention, when you're operating in a lot of languages, and your application is in active development, you're constantly sending out copy for translation. Different translators have different turnaround times and they don't always make it into the release schedule. So, what happens when a translation is missing in a particular language? First we fall back to another region for the same language, then we fall back to English. American English to be specific -- that's the language the developers and product managers write in so there's always an American English translation. Then, we also allow the user to override their browser settings and pick whichever language they want. That is saved to their user profile so wherever they're logged in they'll get the language they have set for our applications. So ya, we give you your configured language whenever possible. But asking us to ignore region is not ideal for most users either.

moepstar 6y ago
The procedure you describe sounds like the sane thing to do / to me :)
marcus_holmes 6y ago
>> For example, your browser's language is set to English. Cool. That's where this example should stop. Your site should then serve me English, because that's the language I've told you that I understand. Why are you changing it based on my location? Why are you serving an English-speaking tourist in Mexico "the appropriate version of our Spanish translations" when their browser just fucking told you THEY WANTED THE ENGLISH VERSION?!!
- goto11 6y ago
  The problem is most users doesn't even know that you can set language preferences at the browser level.
  - gambiting 6y ago
    What do you mean? I don't think we're talking about language preference, simply about...language of the browser itself.
    - marcus_holmes 6y ago
      There's a setting for language preference that is set in the browser, and transmitted in every request header. This is the thing that we're talking about.
      - gambiting 6y ago
        Right, I have no idea how it works(and I guess like was said, 99% of people don't), but as a user I'd reasonably expect that if I have my browser in English, my operating system in English, then I want to see websites in English.
        jobigoud 6y ago
        We don't need to know how it works, it asks the web pages to serve content in that language, it's made explicitly for this use case. It should be the first choice. Second choice could be browser language.
  - self_awareness 6y ago
    If a user doesn't know about it, he probably has the browser set to his native language, which resolves the issue before it's an issue.
    - juliushuijnk 6y ago
pedrogpimenta 6y ago
I feel that should be covered by regional locales set on the browser or system, like EN_US, EN_GB, EN_CA or ES_ES, ES_MX, ES_US. As a user also pointed out, if I'm British and am travelling to the US, changing the date order of an app/website just because I moved is even worse, it can be very confusing.
boomlinde 6y ago
It really is as simple as the article suggests. > 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.
- deleted 6y ago
  [deleted]
yosito 6y ago
Location shouldn't be used at all, unless there is no language set in the browser.
beojan 6y ago
> My best practise is to only look at your region when your selected language has regional variations Or just pick one, and go with it? That way you only need one translation into each language.
otherme123 6y ago
Then you better have human translated 100% accurate versions of your site. Because I've been served "spanish" automatic translations that are gibberish and make no sense. E.g. "data uploading" auto-translated to "los datos cargando arriba", when in proper spanish it should be "subiendo datos". As spanish from Spain I, and I guess more than 80% of spanish people, prefer to read mexican written by a mexican person than "es-ES" translated by a robot. If I'm travelling to Latam, I would prefer your site serving "es-ES", after that "en-US", then "en-UK", and only after that any "es". Just like I have my browser configured. Other Spaniards may disagree and set their preferences differently, and that's fine. It's 100% easier to respect the Accept-Language header than to do geolocation gimnastics.

moepstar 6y ago

The procedure you describe sounds like the sane thing to do / to me :)

marcus_holmes 6y ago

>> For example, your browser's language is set to English. Cool. That's where this example should stop. Your site should then serve me English, because that's the language I've told you that I understand. Why are you changing it based on my location? Why are you serving an English-speaking tourist in Mexico "the appropriate version of our Spanish translations" when their browser just fucking told you THEY WANTED THE ENGLISH VERSION?!!

goto11 6y ago
The problem is most users doesn't even know that you can set language preferences at the browser level.
- gambiting 6y ago
  What do you mean? I don't think we're talking about language preference, simply about...language of the browser itself.
  - marcus_holmes 6y ago
    There's a setting for language preference that is set in the browser, and transmitted in every request header. This is the thing that we're talking about.
    - gambiting 6y ago
      Right, I have no idea how it works(and I guess like was said, 99% of people don't), but as a user I'd reasonably expect that if I have my browser in English, my operating system in English, then I want to see websites in English.
      - jobigoud 6y ago
        We don't need to know how it works, it asks the web pages to serve content in that language, it's made explicitly for this use case. It should be the first choice. Second choice could be browser language.
- self_awareness 6y ago
  If a user doesn't know about it, he probably has the browser set to his native language, which resolves the issue before it's an issue.
  - juliushuijnk 6y ago

pedrogpimenta 6y ago

I feel that should be covered by regional locales set on the browser or system, like EN_US, EN_GB, EN_CA or ES_ES, ES_MX, ES_US. As a user also pointed out, if I'm British and am travelling to the US, changing the date order of an app/website just because I moved is even worse, it can be very confusing.

boomlinde 6y ago

It really is as simple as the article suggests. > 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.

deleted 6y ago
[deleted]

yosito 6y ago

Location shouldn't be used at all, unless there is no language set in the browser.

beojan 6y ago

> My best practise is to only look at your region when your selected language has regional variations Or just pick one, and go with it? That way you only need one translation into each language.

otherme123 6y ago

Then you better have human translated 100% accurate versions of your site. Because I've been served "spanish" automatic translations that are gibberish and make no sense. E.g. "data uploading" auto-translated to "los datos cargando arriba", when in proper spanish it should be "subiendo datos". As spanish from Spain I, and I guess more than 80% of spanish people, prefer to read mexican written by a mexican person than "es-ES" translated by a robot. If I'm travelling to Latam, I would prefer your site serving "es-ES", after that "en-US", then "en-UK", and only after that any "es". Just like I have my browser configured. Other Spaniards may disagree and set their preferences differently, and that's fine. It's 100% easier to respect the Accept-Language header than to do geolocation gimnastics.