ASH NOHE: Let's talk about per-app language preferences.
Before we talk about what this feature is,
let's talk about why it is important.
Imagine you live and work in Zurich
for an international company.
Your work apps are in English.
Your local service apps are in German
because they work better in German.
Your communication apps for which
you use to communicate with your friends and family
back home are in Portuguese.
As another user journey, you speak Bengali and Hindi
fluently.
On your phone, you read the news in Hindi
and send messages in Bengali.
Your phone settings are in English
because it is easier to get help with your phone that way.
In this sense, English is a bridge language.
These users need their app languages
to be different from the system language.
This is what this feature is.
As a developer, you can provide this functionality
to your users in two ways--
first, in device settings, second, in app.
You might choose to do one of these things
or both of these things, and if you do both of these things,
these two things sync.
No matter where your users are setting your application
language, whether that be in the Settings app
or in your application, your app will display
in the correct language.
Let's dive into in-device settings portion first.
On the right-hand side here, you'll
see a GIF of a user navigating to the app languages
page of the Settings app.
The benefit is that this is a centralized location for users
to set any of their application languages,
provided the application has opted into the feature.
To opt into the feature, you'll want
to declare your app's supported languages.
To declare your app's supported languages,
in your Android manifest, you'll provide your localeConfig tag.
That will point to an XML.
The XML is a list of your app's supported languages,
including your app's default locale.
As an app developer, this is the lowest-hanging fruit,
and we recommend to do this first,
unless you already have an in-app language picker.
What if you want to create an in-app language picker?
On the right-hand side, you see an in-app language picker
that allows the user to toggle between English, French, Hindi,
and Japanese.
As the user selects the language,
their UI text updates to be in that language.
The benefit is that users do not need
to leave your application to change your application
language.
It does not require an app restart.
It is handled like a configuration change,
so it is an activity restart.
Developers will also appreciate that this API
is backwards compatible.
Let's dive into how to implement this language picker.
Let's say you have the UI of the language picker built out
already.
When your user goes to select the language,
you'll call AppCompatDelegate setApplicationLocales.
You'll provide a locale list of one element,
and that one element is a locale that the user selected.
You might also want to consider how
you store locale preferences.
For example, let's say your user has set your app language
to be in Hindi.
They entirely close down and start the app back up.
Their expectation is for their app to still be in Hindi.
That means that user preference is stored somewhere.
For Android T and above, we handle that storage for you
automatically.
We can also handle that storage for you
automatically for pre-T devices, provided
that you set autoStoreLocales to true in your Android manifest.
This delegates your locale storage preferences
to AndroidX pre-T. We have this option
because some applications already have an in-app language
picker, and so they are already handling locale storage
preferences themselves.
They might have a reason to set this to false
or to omit this entirely in the manifest,
thereby setting it to false.
Let's talk about this use case a little bit more.
Let's say I already have an in-app language picker
and I'm considering migrating to these APIs.
What are the steps I should take?
We recommend focusing on your in-application language picker
first.
You'll want to migrate to the runtime API,
and you'll recall that the keyword is AppCompatDelegate.
Then you'll want to migrate your storage.
The keyword there is autoStoreLocales.
If you set autoStoreLocales to true,
you are delegating storage to AndroidX,
so you'll hand off your locale storage immediately.
You'll want to do this so that when your application updates,
your users don't see an inconsistent state where
your app does not appear in the language
that they had previously selected
because their preference was lost during the migration.
To prevent that, you'll want to hand off your preferences
immediately.
If you set autoStoreLocales to false,
that means you'll continue to handle your locale
preferences for pre-T, in which case,
you'll only hand off your storage
when you encounter a version change to 33.
After migrating your in-app language picker,
you'll specify your supported locales.
The keyword there is localeConfig.
If there is one takeaway, remember
that the easiest thing to do is declaring
your app's supported languages in the manifest.
This will enable users to change your app language
from their device settings.
If you found this video helpful, then
please Like, Subscribe, and Share
this video with others who might benefit from per-app language
preferences.