Using Android Per-App Language Preferences

The picture is provided by Unsplash

Notwithstanding the fact that multilingual users typically set their system language to one language in most situations, they probably want to select other languages for a particular Android application. Nowadays, to provide Android apps with a better user experience in reality, Google has announced an advanced feature in Android 13, which is called per-app language preferences. This essay aims to discuss some main concepts and best-practices in using per-app language preferences for Android developers.

Introduction and Overview

Initially, Android provides improved support for multilingual users since Android 7.0 (API level 24). This means it allows them to choose multiple locales in settings. Android offers this helpful feature by increasing the number of locales supported and changing the way that the system resolves resources. In fact, multilingual users usually set their system language to one language in most situations; however, they probably want to select other languages for a special Android app. For instance, suppose you live and work in Frankfurt for an international company. Your work apps are in English, and local service apps in German because they work better in German. In addition, communication apps that you use for speaking with your friends is your native Language.

Therefore, to help Android applications support a better experience for users in reality, Android 13 announced an advanced feature, which is called per-app language preferences. There are two ways for providing this new functionality to your users as an Android developer: 1. In device (Device settings) 2. In app (Public APIs). Perhaps, you select to perform one of these methods or both of them in practice. If you want to use both of these ways, these two approaches should be synchronize. It would not be a significant issue where your users are setting your app language, whether that be in the settings app or in your application, your Android app will work in the correct language.

Device Settings

The key benefit of this approach is specifying a centralized location for users to set any of their application languages, and providing the application has opted into the feature. To opt into the feature, you will need to declare your apps’ supported languages. To declare your apps’ supported languages and make sure that your languages are configurable in Android 13 or higher, in your Android manifest, you should mention your localeConfig attribute in a XML file. The XML is a list of your apps’ supported languages, including your app’s default locale. Google has recommend this approach to do at first for Android developers unless you already have an in-app language picker. For example, you should create locales_config.xml to support the following languages you want:

<?xml version="1.0" encoding="utf-8"?>
<locale-config xmlns:android="http://schemas.android.com/apk/res/android">
   <locale android:name="en"/>
   <locale android:name="en-GB"/>
   <locale android:name="fr"/>
</locale-config>

Then, to mention the new file, you should add a line in the Manifest file as follows:

<application
        ...
        android:localeConfig="@xml/locales_config">
    </application>

In-App Approach

Now, the important question is what if you want to create an in-app language picker? When the user selects the language in-app language picker, the UI text can be updated. The key benefit is that users do not require to leave your app for modifying your application language. It does not need an app restart. So, it is managed similar to a configuration change. This means it is an activity restart. In this case, Android developers will also follow the backward compatibility in implementation. Essentially, to address backward compatibility issues with previous Android versions, Google has firmly recommend applying the AndroidX support library when implementing an in-app language picker. When your user wants to choose the language in this case, you will call AppCompatDelegate.setApplicationLocales. You provide a locale list of one element, and that one element is the locale that the user selected.

val onClick = {
  AppCompatDelegate.setApplicationLocales(
     LocaleListCompat.forLanguageTags(
       <the selected locale; en, fr, hi, ja>
     )
  )
}

The important point is that when you are calling setApplicationLocales, it recreates your activity unless your Android application manages locale configuration changes by itself properly.

Moreover, you probably want to consider how you store locale preferences. After choosing a language in-app by a user, it is clear that your app should work effectively in that saved language, which is located somewhere in the Android application. Andorid T and above also manage that storage for you automatically. Additionally, that storage can be handled automatically for pre-T devices if you set autoStoreLocales value to true and android:enabled to false in the manifest. For example:

<application
  ...
  <service
    android:name="androidx.appcompat.app.AppLocalesMetadataHolderService"
    android:enabled="false"
    android:exported="false">
    <meta-data
      android:name="autoStoreLocales"
      android:value="true" />
  </service>
  ...

This delegates your locale storage preferences to Android pre-T. Google has provided this feature since some applications already have in-app language picker, and they are already managing locale storage preferences by themselves. Nevertheless, if you have a reason to create your own custom storage, you can eliminate the manifest entry or set autoStoreLocales to false. To achieve this goal in your app, you have to provide the stored locales before onCreate in the activity lifecycle and gate calls to AppCompatDelegate.setApplicationLocales() pre-T devices. In this situation, Google has recommended a one-time handoff between your custom locale storage solution and autoStoreLocales because it can be useful when your app is first run after upgrading the device to Android 13.

Eventually, for more information, you can follow language-focused intents since enable you to determine the language you like that the invoked app to be in as a best-practice in this area. Also, if you want to invoke a Chrome Custom tab, you should consider Accept-Language Header as another bet-practice.

In Conclusion

Even though multilingual users typically set their system language to one language in most cases, they probably want to choose other languages for a particular Android app. Recently, to provide Android apps with a efficient user experience in practice, Google has announced a modern feature in Android 13, which is called per-app language preferences. This essay considered some main concepts and best-practices in applying per-app language preferences for Android developers based on Google documents and resources.