Why allow users to switch languages
Tags: devtips, localization, i18n
Published: 2022-04-27 11:20:21

<!--kg-card-begin: html-->

## Language vs. Locale

First, let’s say a few words about the difference between languages and locales. If you are new to [**app localization**](https://localazy.com), understanding the difference is a key knowledge.

The language is just a particular language – **English**, **Czech**, **German**, **Italian**, etc. It carries only the information about the language itself and nothing else.

The locale, on the other hand, can be composed of many parameters – language, region (territory), codeset, script. It’s usually associated with cultural conventions (numeric, monetary, date and time formats, writing direction, etc.). However, that information is not encoded in the locale itself.

Also, the language is not always the same, and different locales can use different words – **European Portuguese** vs. **Brazil Portuguese** and **European French** vs. **Canadien French** are commonly known examples.

It’s also possible that the locale contains information about script (writing system), and so the same language can be written using completely different letters – **Traditional Chinese** and **Simplified Chinese** are well-known for this.

## Mobile vs. Web

For web apps, there is no built-in solution for localization. The browser is sending information about the user’s preferences, but implementing the logic is completely on the developer both for the back-end and front-end parts. Usually, there is an option to switch the language/locale, and the most logical choice, based on the user’s preferences, is preset.

Mobile platforms, [**Android**](https://localazy.com/android) and [**iOS**](https://localazy.com/ios), comes with built-in [**solutions for localization**](https://localazy.com/integrations), and they are able to pick the language best-matching the user’s preferences automatically. You only need to add a new translation, and there is nothing else to care about. Everything works!

For me, living in a small country in the heart of Europe, this seems like a perfect solution. We have only one language and no differences in numeric or date and time formats across regions.

There’s a lot of reasons why this is not a perfect solution and why you should allow users to change the language/locale manually.

## Why To Switch Languages?

Certainly, switching languages is not a tool for all your users, but it’s extremely useful for a subset of them.

### The default is not the best

When there is no appropriate language for the user, the platform fallbacks to your default one (the one contained in `values` folder for Android or `Base.lproj` for iOS). The common pattern is that the default language is English, but it may not be the case.

Anyway, the default choice may not be the best one for the user, so if she’s given the option to change the language, she appreciates it.

As an example, the **Czech** and **Slovak** languages are very close yet they are considered two different languages. We, Czech people, understand the Slovak language pretty well, and Slovaks understand the Czech language. Many years ago, we were a federation, a single country. Many Slovaks study in the Czech Republic nowadays, and they can attend university and finish it in the Czech language. They even can write seminars in Slovak, and the teachers accept it. That demonstrates how close the languages are.

However, if the Czech translation is available and Slovak not, your app fallbacks to English for Slovaks. Do you see the problem? Slovakia is a small country – it’s just about 6 million potential users 😃.

From Android 7, it’s possible to set several preferred languages, but many users still don’t know about this option and don’t use it. They usually select their language in the welcome wizard – and there’s typically no option to select more preferred languages – when they start the phone for the first time and never think about it again.

I did my small research, and not a single person out of people around me has set both Czech and Slovak languages as they preferred locales even if it makes perfect sense.

### Bilingual users

This is a similar situation to the previous one.

There are plenty of bilingual users with English not being any of those languages they know. Better to say, with any of the languages they can speak not being the default one in your app.

So when their native language is not available in your app, they would choose a different option other than your app’s base language.

And the situation may be even more complicated with regions – someone from Latin America who can speak Spanish and Portuguese is more likely to select Brazil Portuguese, and someone from Europe would probably go with Portugal Portuguese. While these variants are close, some words are completely different.

I would bet that the majority of them don’t know about the option to set more preferred languages on Android 7+, I wrote about above.

### Different script is better

Some languages use more different scripts (aka [writing systems](https://en.wikipedia.org/wiki/List_of_writing_systems) - simplified, we can talk about them as letters used for writing in the given language). In Chinese, there is a traditional and simplified form. Azerbaijani can use Latin, Cyrillic or Arabic letters. And so on.

While the automatic resolution can find the correct language, the user may not read the given script, so switching language may be a handy option. Also, the locale resolution engine – depending on its implementation – may be unable to find the language in a suitable script, and therefore, it can fallback to the base language. None of these options is wrong, but certainly, none of them is perfect.

Can you see the problem? If your language has only one written form, you may not even realize how big of an issue this can be.

### Language selection useful for some countries

Some countries have several different languages and variants in use. India is one of them.

This is actually something I wasn’t aware of until one of our users from India explained to me the situation. It’s not always the question of a simple language resolution, and the situation is so complex that the only option is to let users choose their preferred locale.

![Language locale](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nbvhsv2ojhvtzk8rsqll.png)

He considered the option for switching languages as required prerequisites for using [Localazy](https://localazy.com), and fortunately, our [Android library](https://localazy.com/docs/android/localazy-android-library) comes with a great implementation, so he happily used it.

As you can see, there are specific situations that we can’t fully understand or even know about, but they are important enough to be the top priority for particular developers.

### Different language in phone

This is probably not a big issue, but there are also users with a different language set as the primary one in their phone. Why? In my case, it’s because of the voice assistant. As I use the phone instead of navigation in the car (with Android Auto), I need it to understand me.

It’s quite common for users to switch the phone to a language they are trying to learn. But for your particular app, they may be willing to use their native language instead.

I can imagine that I would rather use a language I’m familiar with for my stock trading app and not accidentally sell my Tesla or Apple stock because of a lack of knowledge of the vocabularies 😃.

### Attract more volunteers to localize your app

All situations described above are about our users and their particular needs and their different situations. However, there is also a great reason for implementing language switching for your app’s good - to attract more volunteers.

Having the option to switch languages is like having a dedicated space to communicate with your users. They can see which languages are supported, which not, which languages are fully translated, and where they can help you. You can ask them to help you, and if you do, they are more likely to come and contribute new translations to your app.

That is, in turn, a way how to get more users for your app. My [Floating Apps](https://floatingapps.net) skyrocketed in Japan only after it became available in Japanese.

And Teo, the user of [Localazy](https://localazy.com), translated his [Birthday Reminder](https://localazy.com/case-study/birthday-reminder-app) to more languages to grow it significantly:

> With Localazy, I discovered that there are some markets where it is very important that the app is translated into the local language. I have seen growth in specific states like Brazil, Mexico and Russia. Just for translating the app! In addition, it has also improved the reviews since especially in Russia they leave bad reviews if the app is not translated into their language … Not long ago I also translated the app into Arabic and I’m starting to see the first positive effects especially for regarding in-app purchases. \[Teo Coding, Author of Birthday Reminder]

### How to improve app reviews significantly

Some users are more likely to rate your app lower if it doesn’t speak their language. Contrary, you are more likely to get positive reviews with a multilingual app.

In some countries, this is more common - for example, in **Russia**. Also, I saw users from **Brazil** to prefer their native language more than people from other countries. As you can see, Teo above has a very similar experience.

A high rating of your app is extremely important for sustainable growth, so if you can attract more volunteers and contributors, you can, in turn, also get more users in general. And that’s a simple win-win and another argument for offering your users an option to switch language - and thus opening a new communication channel with them.

## The Right Way to localize apps

Are you considering to [localize your app](https://localazy.com/blog/improve-mobile-app-localization-efficiency-with-localazy)? Do you plan to add an option to switch languages? Do it the right way.

Do not hesitate to use [Localazy](https://localazy.com), and feel free to contact us for help 😉.

<!--kg-card-end: html-->