Comment by Cthulhu_ | Hacker News Reader

Comment by Cthulhu_ | Hacker News Reader

Parent Full thread

I built an iOS app once for a Dutch audience. We used the device's language as the app's language, because that makes sense, right? It's the same with the preferred language in a browser, right?

Wrong; we got complaints from users that their app was in English instead of Dutch. Even though their device was set to English or another unsupported language.

We begrudgingly added an app specific language preference. I repeated this later on for a package shipping webapp where on the login screen (and elsewhere iirc?) you can select a language; it defaults to your browser's Accept-Language header, but allows the user to override it.

Lesson learned; Accept-Language is fine for the initial language, and if that header is not to be trusted, maybe IP / geolocation based. But always offer an easy way to set the language; you may be dealing with someone who doesn't live in the country of origin on a device / browser that isn't theirs.

Also remember that location, locale and language are three different concepts entirely.

First and foremost, thanks for having a very sane approach to this ! This is what other apps should tend to.

> We used the device's language as the app's language, because that makes sense, right?

One of the mistake devs do all the time is assuming users use _one_ language. It’s not the case for a very large portion of people around the globe.

> It’s not the case for a very large portion of people around the globe.

Yep, even people who speak one language might put their phone or browser into another language for learning (immersion) purposes but need your important (e.g. banking) application to be in their native language regardless.

Yepp, just look at other responses here in this thread. People often assume that there is a system language that is used in the browser; that is only partly true, browser settings allow to specify multiple languages with given priority. It is just usually the default system language, until you configure it. The browser might not even use the system language in that setting at all if you configure otherwise.

And then there's the technical audience: I use all my devices in English, as usually the translations are subpar. On the other hand, I expect the local apps (ie, banking, some e-gov app, your package shipping example, etc) to be in my native language, as usually, the translations are even worse due to the developer's budget allocated to localization. Conversely, when I'm travelling and need to use some local app (airline, rideshare, taxi, etc) I hope that it is able to at least have some English translation.

Yeah, please offer the option to set the language to the user.

That's exactly my approach as well. My devices are usually in English, as it's the "lingua franca" of the OS and the internet. For non country-specific applications, it's much harder to search for, well, any issue if your OS/browser/IDE/complex application is not in English.

On the other hand, I want my local apps to use the local language, as they were developed with the native language in mind first for a use case that makes sense with that specific locale in mind, and it just doesn't make sense to be reading an English translation of something that you're used to see expressed in your local language. An English translation in that case is usually not only subpar but confusing if you're also fluent in the local language.

My ideal would be to somehow state that, say, "I speak English and German. My preference is to have content displayed in what you consider the "native" language of your application if it's on that list, otherwise my preference is English, then German."

In practice, no one would bother setting this up (as we see in the case of Accept-Language) and no one would bother implementing this correctly. The next best thing is just an application/website specific language override, which is easily explainable to any user.

All my devices are set to English. But my bank’s app is in Polish (using the app-specific override), partly because their English translation is mediocre, but also because I’d rather not do something dumb with my money due to a mistranslation/misunderstanding/different interpretation. Same goes for other local experiences. eg. takeway.com — the restaurant menus would likely be in Polish anyway (though I can see some translated ones as well).

I'm in a similar boat as you, Switzerland is multi language (German, French and Italian) and quite a few users (including myself) use English as system language. Luckily by now you can change the language of iOS applications in the settings app. Though guess what... no one knows or finds that setting. So yes, it's best to let the user decide just as you write.

It's frustrating that again and again I run into the same sort of root issue. There exists UI to configure something but it's either hard to find, hard to change, people want to leave that setting as-is but still want your webpage/app to behave differently, or people don't even know about it. What this leads to having to wrap "native"/"system" UI for almost any option that decent number of users might want.

Dark mode is another good example of this. A lot of app developers weren't able to just respect the system setting, instead they had to add a toggle/select to their options so users could pick "Follow system", "Always Light", or "Always Dark". Same thing with language and you never please everyone. If you add a website/app setting to change language there will be some number of users who complain that your app isn't following system settings (even if you set your own internal setting initially to match the system). You can normally satisfy most people with a "Follow System" or "Hardcode to X value" but it always feels a little gross to add yet another level of settings. In the same way you will almost never get a native Push Notification (or other permission) dialog in an app, first they pop their custom dialog and only if you say "Yes"/"Enable" will they pop the system one. I understand why and I've implemented this multiple times but it feels like there has to be a better middle ground between "You can only show the permission dialog once" and "You can spam it over and over indefinitely", I always hate having to create the "It looks like you've disabled this notification, here is how you can turn it on in your device settings"-screen.

Did you suggest they change their device settings? Yours was probably the right approach, I’m just curious whether we have actual data to support that people prefer this split configuration, and aren’t just suffering under bad defaults.

Reply on news.ycombinator.com