Hacker News Reader

Comment by atemerev | Hacker News Reader

There are many many cases when you can’t determine user’s language by location only (immigrants, VPNs, business trips, multinational corporations, countries where people speak multiple languages, etc). If you do any effort in localization, you should recognize Accept-Language. If unsure, you should ask the user for their preferred language directly. Inferring the language by location is not acceptable.

Here in Switzerland, I am so tired of websites offering German localization by default. We don’t speak German in Geneva.

View on HN

At work we have it implemented as follows:

1. Check if there is a language cookie set previously 2. If no cookie, check if the Accept-Language is present and contains one of the supported locales 3. If no Accept-Language matches, use the fallback application language

Not that hard to implement, except perhaps parsing the Accept-Language preferences with their quality value can be cumbersome.

How does the language cookie get set in the first place? Is there any option for the user to set his preferred language?

It is a part of browser's settings (for Chrome and Firefox at least), and it is default to system's default language I think.

You’re talking about the Accept-Language header. They are asking about the cookie.

To answer the question, yes, normally you would have some kind of manual switcher that sets the cookie. Please don’t use flags for this, because flags indicate countries, not languages. Don’t make a Russian-speaking Ukrainian seek out the Russian flag, and don’t make an English-speaking Irish person seek out the Union Flag.

> To answer the question, yes, normally you would have some kind of manual switcher that sets the cookie. Please don’t use flags for this, because flags indicate countries, not languages. Don’t make a Russian-speaking Ukrainian seek out the Russian flag, and don’t make an English-speaking Irish person seek out the Union Flag.

Yes, why make things easy. :-)

Controversial opinion: Flags are great as a visual aid, shorthand, look neat, and give a better UX for 90+% of users, even if it hurts some linguists' and nationalists' feelings.

Better yet: Offer en_CA, en_GB, en_IE, and en_US, with appropriate flags.

(Bonus point for fr_CA with the CA-QC flag)

But then where's the flag for Liberia and Belize and Singapore? What if I'm in Indonesia and you don't offer an Indonesian option but I know enough English to get by - what country's flag should I click?

Just don't use flags, man. It's ridiculous that this is even still a discussion.

I dunno, which flag would serve as a comprehensible shorthand for Arabic? How many Arabic readers would recognise that flag? How many Spanish speakers would recognise the Spanish flag?

If you use flags I would still recommend putting the language name in the language next to it, for example the French flag next to 'Français'.

Its not just a matter of hurt feelings, it has multiple problems. If it was just hurt feelings I might agree with you, but it is ambiguous, inconsistent and fails to cover many cases. That is bad UI.

What flags to you suggest people use for Cantonese, Tamil, Arabic and Xhosa?

Why use the Union flag for English? If the language is en-US surely an American flag would be more accurate? You can then use the British flag for en-GB. However, if you offer Welsh you would use the Welsh flag (and presumably the Scottish one for Scottish Gaelic, although I cannot recall ever seeing that) so it would surely be more consistent to use the English flag for British? Even for or generic English?

I gave an example of Russian-speaking Ukrainians. Why are you characterising this as “hurting some linguists' and nationalists' feelings”? It’s not nationalism or pedantry to be offended at being forced to identify with the flag of the country that is currently murdering your friends and family.

I like when the language is in it's own name, eg: Suomi -- makes it easier to find.

Except when the names are in non-Latin script and therefore sorted arbitrarily.

Same as what we do. Only one additional thing: when people log in to their accounts, it switches to the preferred language for that account (and any changes in language selection whilst logged in are also saved into the account preferences).

> Not that hard to implement, except perhaps parsing the Accept-Language preferences with their quality value can be cumbersome.

Many web frameworks provide a tool for parsing these for you. If yours doesn't (or you're not using one) you may be able to find a package that does. Some will also do the matching for you, so you can pass it a list of languages you can support alongside the Accept-Language string and it will pick the best option that's found in both.

For example, here's the documentation for such a method in the excellent Nette PHP framework that I've been using where I can lately: https://doc.nette.org/en/http/request#toc-detectlanguage

But I've also used this stand-alone package: https://packagist.org/packages/willdurand/negotiation

Ruby on Rails has built in localization and actually respects whatever headers the user agent sends

`Accept-Language` contain both language and locale. Depending on your app you might have supported languages or language/locale combinations. When there's no exact match after step 2, you'll want to do a partial-match on only the language.

Reply on news.ycombinator.com