Hacker News new | past | comments | ask | show | jobs | submit login

Sigh, that's sad.

It baffles me that there are still so many services that try to 'automagically' intuit which language someone wants to have a service in, instead of just simply .. asking.

Google play is a prime culprit, for example, showing a mixture of language content on the play store. See also subtitles, dubbed content, books..

Another one - Sony's Playstation store, where if you choose a country, then the language (despite them having the assets available through their international presence) is permanently set and impossible to change.




> It baffles me that there are still so many services that try to 'automagically' intuit which language someone wants to have a service in, instead of just simply .. asking.

My experience is that language/locale implementation for a big project is so complex that PMs like to handwave the language selection part away. On a recent project I had to go back and ask, "What if an english-speaking user is traveling in Germany, do we show them the German-language site? What if a German-speaking user is traveling to France, do we show them English (since we didn't have an FR localization)?"

Confounding the issue is that many implementations combine locale with language, which can be a problem if you have locale-exclusive features. As a made-up example, maybe Cortana's contract for stock data specifies it can only be used in the US, and you're a US-based Spanish speaker. But Cortana assumes Spanish == Mexico, so if you use Spanish now stock quotes don't work. It's really attractive to just call those problems edge cases to be worked out in the next release.

(I think Etsy handles this really well, you can specify ship-to location, interface language, and currency separately. Although for some reason they auto-detected me, in the Bay Area, as UK, EN-GB, CAD which was strange. Obviously some work to be done.)


When I was in China for a while, a frustrating thing was that many websites I've visited often started assuming and practically insisting that I knew Chinese. There was more than one site that I couldn't figure out how to switch back to English. I checked that my browser was still giving the "Accept-Language: en-US,en;q=0.5" header, but clearly websites know better than me.


Accept-Language is fun. I have an accept-language that orders them en, ja, other. aa.com (American Airlines) then uses that to display the content to me in English, except dates and times which always appear in Japanese (12月25日 午後1時10分). Fun times.


For a while I had my system language preferences set as en-UK, ja, en-US and every so often I'd get an installation that was in Japanese because there was no UK English version.


The country code for the United Kingdom is GB, not UK. There's no such language code as en-UK. British English is designated en-GB.


That sounds correct behavior to me. You should add a plain "en" before ja.


Is that a problem? It sounds like what you asked for.


Some browsers used to send a default Accept-Language that specified English without asking the user (and, IIRC, even if the UI language of the browser was different). Thus, many sites still ignore those particular values of Accept-Language. This seems to be one of them.


There are definitely more web browsers in China that have the Accept-Language header wrongly set to English, than there are English readers there who want English. So the websites may not know better than you, but they know better than the majority of the web browsers. It's not perfect, but they are making the correct general decision IMO.


> web browsers in China that have the Accept-Language header wrongly set to English

How? Seriously, how? Assuming the browser's interface is in Chinese, the Accept-Language header should be set properly.


I don't think there's a problem with automagically inferring the language. It sounds like the problem lies in not being able to override that decision.


The route to revert language must be clear though, even when the UI is in a foreign language.

This can be trickier than it sounds. For instance, selecting English from a Japanese UI should be "English" not 英語. Conversely, from English to select Japanese has to be 日本語 not "Japanese".


That's exactly the thing, in an ideal world it would try to infer the language automatically, but still let you change it if you are not happy with it.


Well then you open up the possibility of being unable to override the language because you cannot interpret the one inferred.


Worst one for me is Google Now's voice service (simply because that's the only one I've ever really used).

Many features and recognition roll out to English (US) first and remain unavailable to me for a long time. I'm in Canada. It's the exact same language, just with some extra "u"s scattered around in the written form.


> It baffles me that there are still so many services that try to 'automagically' intuit which language someone wants to have a service in, instead of just simply .. asking.

Well, because they should and rightfully so. You shouldn't have to select a language every time you start an app. Instead it should use whatever language was set on your system. Anything else just isn't intuitive and would add more friction before a user could get anything meaningful done.

The parent comment was referring to Cortana only working with English and thus assumes the user can't speak English as he has his system set to Spanish. That's an unfortunate edge case but one that could be overcome with advanced settings should they want to deal with it. But again, the anecdote is an edge case and shouldn't be used to go against best practices in regards to localization.


Localization is all about edge cases, though. If you ignore edge cases, you'll ignore most world languages, after all.

By all means, make a guess at what language to use, but always allow the user to choose in case you guess wrong.


> Localization is all about edge cases, though. If you ignore edge cases, you'll ignore most world languages, after all.

The edge case of someone setting their device to a different language than the one they want to use in a specific application is not one of localization but of usability.

> By all means, make a guess at what language to use, but always allow the user to choose in case you guess wrong.

While I agree I wouldn't call it a guess as it's a setting a user set when setting up their device.


You make the problem sound more obscure than it actually is, which to be fair is very understandable (and I guess common) if you're from an English-speaking country.

Many people outside of those know English well enough that they'd rather have a feature in English than not at all.

Also, many if not most applications and services that aren't billion-dollar businesses or otherwise have had insane amounts of resources poured into them have terrible localization. And even if the localization is good, it can be beneficial to use the English version.

English is the international language, it is taught to children all over the world, it is used in business, academia and so on, all over the world. You know that, everyone knows that, but sadly, to all-English dev teams, it is all too often an afterthought.

And that doesn't even take expats, travelers etc. into account, who might want to use their native language system-wide but need certain applications to use the local language, or vice versa.


I would say that UI language and speech input language are different enough that taking them to be the same would qualify as a good guess, not simply obeying a setting.

Apple takes this approach with Siri, for example.


I'm used to switch between three different languages to take advantage of the prediction thing in the default android keyboard and I think it's very comfortable, just one or two taps and you are ready to go.


> It baffles me that there are still so many services that try to 'automagically' intuit which language someone wants to have a service in, instead of just simply .. asking.

There's a simple explanation for that. Adding a UI may end up being much more involved than a somewhat complicated guessing infrastructure. And if that's fine for most of users, an organization might not care enough to make it better.


It baffles me that there are still so many services that try to 'automagically' intuit which language someone wants to have a service in, instead of just simply .. asking.

They are damned if they do and damned if they don't. If they don't automatically intuit users will call them lazy or declare it bad UX for not using the same language the phone is set to.


If only it was possible to automatically determine sensible defaults, but override default settings in applications.


Except, at least for Android, it's not easy to override the language settings just for an app.


Both of your examples could easily be licensing issues though.


Honestly, at least when it comes to Android development, it's far, far easier to "intuit" (use the phone's default language) than it is to let you choose on a per app basis. The system will automatically select the proper resources, meaning I don't have to write special code to load a Spanish string instead of the English one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: