Android Builders Weblog: Per-App Language Preferences


Posted by Neelansh Sahai Android Developer Relations Engineer (on Twitter and LinkedIn)What you probably have a set of customers who’re fairly fluent in English, Hindi, and Spanish, they usually have a information app on their telephones and like to learn the information in Hindi? For his or her texting app, they like Spanish as they’ve some family and friends who they textual content with in Spanish. However for ease of entry, they nonetheless choose their machine to be in English. Now there are lots of such use-cases the place the customers may need their app languages to be completely different from their system language. Attention-grabbing!

Beginning with Android 13, we now have included one of many most-requested options from customers, Per-App Language Preferences. It lets customers change app languages from System settings, offering customers with higher management over their language decisions for various apps, no matter the system language.
A cellphone screen displaying App language preferences in system settings for the YouTube app

Construct to your multilingual customers

This weblog focuses on learn how to combine the Per-App Language Preferences API in your app to supply your customers the flexibleness to decide on completely different languages for various apps.

1.    Customers can change the language settings from system settings by deciding on: 

Settings → System → Languages & Enter → App Languages → [Select the desired App] → [Select the desired Language]

NOTE: Solely these apps which have opted in for the characteristic by specifying the locale_config.xml file (extra on this under), will seem in system settings.

A cellphone screen demonstrating finding the language settings from system settings by selecting Settings → System → Languages & Input → App Languages → [Select the desired App] → [Select the desired Language]

2.    In case your app already has an in-app language picker, you’ll be able to combine the Per-App Language Preferences API to leverage the complete platform help. For pre-Android 13 customers, the system settings received’t be seen, however builders can nonetheless present an in-app language picker.

A cellphone screen demonstrating integrating the Per-App Language prefences API for an app which already has an in-app language picker

Easy methods to combine this characteristic in your app?

There are 5 steps that must be adopted whereas engaged on the Per-App Language Preferences characteristic, listed right here →

 

1.    Create locale_config.xml file

Create a brand new file in values/xml/ listing and title it as locale_config.xml. This file ought to include an inventory of all of the locales which are supported by the app. The checklist component ought to be a string containing a locale tag.

NOTE: The locale tags should comply with the BCP47 syntax, which is often {language subtag}–{script subtag}–{nation subtag}. Something apart from that shall be filtered out by the system and will not be seen within the system settings.

locale_config.xml

<?xml model=“1.0” encoding=“utf-8”?>
<locale-config xmlns:android=“http://schemas.android.com/apk/res/android”>
   

    <!– English –>
    <locale android:title=“en”/>

    <!– Japanese (Japan) –>          
    <locale android:title=“ja-JP”/>

    <!– Chinese language (Macao) in Simplified Script –>
    <locale android:title=“zh-Hans-MO”/>

    <!– Chinese language (Taiwan) in Conventional Script –>
    <locale android:title=“zh-Hant-TW”/>  
    …
</locale-config>

2.    Add the locale_config within the AndroidManifest.xml

Specify this locale_config.xml file within the app’s AndroidManifest.xml

AndroidManifest.xml

<manifest>
    …
    <software
       
        android:localeConfig=“@xml/locale_config”>
    </software>
</manifest>


After steps 1 & 2, your customers will have the ability to uncover and set their language desire to your app from system settings on units working Android 13 or greater. In case your customers are on units working on variations decrease than Android 13, you’ll be able to present an in-app language picker. Optionally, you may as well embody the identical language picker in your app for units working Android 13 or greater. When your app consists of an in-app language picker, it is necessary for the consumer’s preferences to be in sync between the system and the app. That is the place the AndroidX APIs come into the image. Learn on to learn to create an in-app language picker.

Use the newest model of AppCompat Library

def latestAppCompatVersion =  “1.6.0-rc01”

dependencies {
    …
    implementation “androidx.appcompat:appcompat:$latestAppCompatVersion
    implementation “androidx.appcompat:appcompat-resources:$latestAppCompatVersion
    …
}

4. Use AndroidX APIs

Use the APIs in your code to set and get the app locales.

MainActivity.kt

val appLocale: LocaleListCompat = LocaleListCompat.forLanguageTags(“xx-YY”)

// Name this on the primary thread as it could require Exercise.restart()
AppCompatDelegate.setApplicationLocales(appLocale)

// Name this to get the chosen locale and show it in your App
val selectedLocale = AppCompatDelegate.getApplicationLocales()[0]

NOTE: These APIs are additionally backward appropriate, so even when the app is getting used on Android 12 or decrease, the APIs would nonetheless behave the identical, and no further checks for OS variations are required in your code.

 

5. Delegate storage to AndroidX

Let AndroidX deal with the locale storage in order that the consumer’s desire persists.

AndroidManifest.xml

<software
   
    <service
        android:title=“androidx.appcompat.app.AppLocalesMetadataHolderService”
        android:enabled=“false”
        android:exported=“false”>
        <meta-data
            android:title=“autoStoreLocales”
            android:worth=“true” />
    </service>
    …
</software>


Steps 3, 4, & 5 above reveal the minimal elements wanted to create an in-app language picker.

And with this, your app can now help locale switching.

Further issues to handle whereas migrating to the API

Earlier, builders needed to deal with the consumer’s preferences on their very own, both by utilizing SharedPreferences, storing the info on a server, or different app logic. With the new APIs, there is no such thing as a must deal with this individually. So when you’re utilizing these APIs, AndroidX is already taking good care of the storage half, however what occurs when the app is opened for the primary time after a consumer updates their machine to Android 13 or greater?

On this case, the system received’t concentrate on the consumer’s preferences for the app language and thus it’ll map the app to the default system language. To keep away from this, builders want so as to add some one-time migration logic in order that their customers don’t need to set the language once more once they replace the app.

Right here is an instance of the migration that may be completed in the event you had been utilizing SharedPreferences earlier to retailer the consumer’s language desire.

// Specify the constants for use within the under code snippets

companion object {

    // Constants for SharedPreference File
    const val PREFERENCE_NAME = “shared_preference”
    const val PREFERENCE_MODE = Context.MODE_PRIVATE

    // Constants for SharedPreference Keys
    const val FIRST_TIME_MIGRATION = “first_time_migration”
    const val SELECTED_LANGUAGE = “selected_language”

    // Constants for SharedPreference Values
    const val STATUS_DONE = “status_done”
}

// Utility technique to place a string in a SharedPreference
personal enjoyable putString(key: String, worth: String) {
    val editor = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE).edit()
    editor.putString(key, worth)
    editor.apply()
}

// Utility technique to get a string from a SharedPreference
personal enjoyable getString(key: String): String? {
    val desire = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE)
    return desire.getString(key, null)
}

// Verify if the migration has already been completed or not
if (getString(FIRST_TIME_MIGRATION) != STATUS_DONE) {

   // Fetch the chosen language from wherever it was saved. On this case it’s SharedPref

   // On this case let’s assume that it was saved in a key named SELECTED_LANGUAGE
  getString(SELECTED_LANGUAGE)?.let { it

      // Set this locale utilizing the AndroidX library that may deal with the storage itself
      val localeList = LocaleListCompat.forLanguageTags(it)
      AppCompatDelegate.setApplicationLocales(localeList)

      // Set the migration flag to make sure that that is executed solely as soon as
      putString(FIRST_TIME_MIGRATION, STATUS_DONE)
  }
}

 

What flexibility does the characteristic present to the customers and builders?

Right here are some things that may show to be helpful for you customers.

  1. All units working Android 13 or greater may have a typical place for customers to find and alter the language of their apps.
  2. Though the system settings are restricted to the units working Android 13 or greater, the AndroidX APIs are backwards appropriate. Thus, there is no such thing as a requirement so as to add OS Model checks in your code whereas constructing to your multilingual customers.
  3. Builders don’t must deal with configuration modifications individually or fear about storing the consumer’s chosen language each time. The API handles configuration modifications and shops the language preferences for you.
  4. Works with different Android options like Backup and restore. If a consumer switches to a brand new machine and restores the beforehand backed up knowledge, your app will retain the consumer’s final most well-liked language, thus offering your customers with a greater and extra seamless expertise.

Recap

With that, most components of the characteristic are lined. So let’s have a fast recap on what we mentioned in in the present day’s learn.

  1. A fast learn on what Per-App Language Preferences provide to multilingual customers and app builders.
  2. What finish customers will see on their units.
  3. Easy methods to migrate your app to the Per-App Language Preferences APIs.
  4. A couple of issues that must be taken care of whereas migrating to the APIs to make sure a greater consumer expertise.
  5. Lastly, the advantages that finish customers and builders can leverage from this characteristic.

    References

    1. Per-App Language Preferences
    2. Pattern App ( Compose )
    3. Pattern App ( Views )
    4. Per-App Language Preferences (YouTube Video)
    5. Per-App Language Preferences – Half 2



Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles