Tag Archives: API

Per-App Language Preferences – Part 2

Posted by Neelansh Sahai Android Developer Relations Engineer (on Twitter and LinkedIn)

Context

In part 1 of the Per-App Language Preferences blog, we discussed what the feature is, how developers benefit from it, how to implement the feature, and the strong business impact of catering to multilingual users. In this part of the blog, we'll discuss how various top apps migrated to the Per-App Languages Feature and how it benefited them.

Developer Success Stories

Here are some top apps that migrated to the Per-App Languages Preferences APIs. Let’s have a look at them.

LinkedIn is a business and employment oriented online platform that is primarily used for professional networking and career development. It bridges the gap between an employer and a job seeker, by providing both a common ground to connect. LinkedIn operates over a huge set of 875+ M registered users spread across more than 200 countries and territories.

Due to the several regions they cover, it becomes important to support multiple languages in the app. LinkedIn supports 26 Languages in their app right now, and this brings forward an opportunity to provide the users with the best experiences of latest android features. With this as the target, the LinkedIn team invested their efforts in migrating to the new Per-App Language Preferences APIs, and went ahead to provide their consumers the complete flexibility and features of Android 13. The team also quoted, “It was an easy integration with minimal code changes”.

MyJio is the-one-stop destination for recharges, managing accounts & Jio devices, UPI & payments, entertainment services with movies, music, news, games, quizzes & a lot more. With over 500 M+ total installs spread across the globe, MyJio aims to provide its users better access to a variety of utilities. Also as the user-base of MyJio is quite vast, the app supports a total of over 12+ Languages. With these many features and a wide diversity of active multilingual users, MyJio has a strong reason to localize their app using the best practices.

MyJio developers implemented the Per App Language Preferences APIs right along with the Android 13 release, allowing their users the flexibility to select a language for their app from system settings as well.

One of the major use-cases was to retain user's language preference, when users switch devices and then log in again from the same account. In this case, when the data is restored from a previous backup, the language preference is also restored along with the rest of the data, maintaining the seamless MyJio user experience across devices. This shows the API's flexibility to work well with other Android features like Backup and Restore, and helps developers give their users a better user experience.

With over 16.7M+ monthly transacting customers in more than 1000 cities across India, it is one of the most popular food ordering and restaurant discovery services in the region. This also means that the app is used in several languages. Zomato currently supports over 15 languages on its app.

The Zomato team wanted to make the user experience for users across geographies to be very seamless and delightful. Localizing the app based on the region and user preference was an important step in this direction. Zomato was quick to respond to the changes that were introduced in Android 13. They went ahead and migrated their language-switching logic to Per-App Language Preferences, within a week. Thereby helping their users find an easy way to use Zomato in their preferred language.

FROM THE DEVELOPERS :

At Zomato, providing the best customer experience possible is the core of our business and we believe localization is very critical in giving our customers a pleasant experience on the platform. Our team integrated with the new A13 Per-App Language Preferences API provided by Google to make it easy for our users to switch their preferred language on Zomato.

The ease of integrating the API helped us get it done effortlessly in less than a week’s time. Backward compatibility and stability of the API ensured that we are not compromising on the experience of our customers. With this, we hope to provide a better experience to the customer in their journey of online ordering via Zomato.

OkCredit is a credit management app with over 50M+ downloads, having total annual transactions of around 50 Billion USD on the app. As OKCredit supports both local and large-scale businesses and also around 10+ languages in their app, it was critical for them to support the ability to seamlessly switch the app language so that more users are able to onboard on their platform.

The developers from OkCredit have always been quick to adopt changes introduced in Android. They recently adopted the Per-App Language Preferences APIs within the timeframe of a week, providing their end users a better and more seamless experience around switching their app languages at their convenience.

FROM THE DEVELOPERS :

The demand for using apps in vernacular language is steadily growing in India. After Google announced Per-App Language Preferences recently, it was a straightforward decision to integrate them. The implementation was straightforward, stable, and compatible with older Android versions.

Conclusion

We saw that some top apps have implemented the Per-App Language Preferences APIs in their apps and have also circulated the updates out to the users. This easy migration was possible in such a short timespan due to the low amount of effort investment and minimal code changes required. Lastly, here are some resources that can help you understand the feature better.

Source: Android Developers Blog

Per-App Language Preferences – Part 1

Posted by Neelansh Sahai Android Developer Relations Engineer (on Twitter and LinkedIn)What if you have a set of users who are quite fluent in English, Hindi, and Spanish, and they have a news app on their phones and prefer to read the news in Hindi? For their texting app, they prefer Spanish as they have some friends and family who they text with in Spanish. But for ease of access, they still prefer their device to be in English. Now there are many such use-cases where the users might want their app languages to be different from their system language. Interesting!

Starting with Android 13, we have included one of the most-requested features from users, Per-App Language Preferences. It lets users switch app languages from System settings, providing users with better control over their language choices for different apps, irrespective of the system language.

A cellphone screen displaying App language preferences in system settings for the YouTube app

Build for your multilingual users

This blog focuses on how to integrate the Per-App Language Preferences API in your app to provide your users the flexibility to choose different languages for different apps.

1. Users can change the language settings from system settings by selecting:

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

NOTE: Only those apps that have opted in for the feature by specifying the locale_config.xml file (more on this below), will appear in system settings.

2. If your app already has an in-app language picker, you can integrate the Per-App Language Preferences API to leverage the full platform support. For pre-Android 13 users, the system settings won’t be visible, but developers can still provide an in-app language picker.

How to integrate this feature in your app?

There are 5 steps that need to be followed while working on the Per-App Language Preferences feature, listed here →

1. Create locale_config.xml file

Create a new file in values/xml/ directory and name it as locale_config.xml. This file should contain a list of all the locales that are supported by the app. The list element should be a string containing a locale tag.

NOTE: The locale tags must follow the BCP47 syntax, which is usually {language subtag}–{script subtag}–{country subtag}. Anything other than that will be filtered out by the system and won't be visible in the system settings.

locale_config.xml

<?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="ja-JP"/>

<locale android:name="zh-Hans-MO"/>

<locale android:name="zh-Hant-TW"/>
...
</locale-config>

2. Add the locale_config in the AndroidManifest.xml

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

AndroidManifest.xml

After steps 1 & 2, your users will be able to discover and set their language preference for your app from system settings on devices running Android 13 or higher. In case your users are on devices running on versions lower than Android 13, you can provide an in-app language picker. Optionally, you can also include the same language picker in your app for devices running Android 13 or higher. When your app includes an in-app language picker, it's important for the user's preferences to be in sync between the system and the app. This is where the AndroidX APIs come into the picture. Read on to learn how to create an in-app language picker.

3. Add the libraries

Use the latest version of AppCompat Library

build.gradle (app)

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")

// Call this on the main thread as it may require Activity.restart()
AppCompatDelegate.setApplicationLocales(appLocale)

// Call this to get the selected locale and display it in your App
val selectedLocale = AppCompatDelegate.getApplicationLocales()[0]

NOTE: These APIs are also backward compatible, so even if the app is being used on Android 12 or lower, the APIs would still behave the same, and no additional checks for OS versions are required in your code.

5. Delegate storage to AndroidX

Let AndroidX handle the locale storage so that the user's preference persists.

AndroidManifest.xml

Steps 3, 4, & 5 above demonstrate the minimum components needed to create an in-app language picker.

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

Additional things to take care of while migrating to the API

Earlier, developers had to handle the user's preferences on their own, either by using SharedPreferences, storing the data on a server, or other app logic. With the new APIs, there is no need to handle this separately. So when you are using these APIs, AndroidX is already taking care of the storage part, but what happens when the app is opened for the first time after a user updates their device to Android 13 or higher?

In this case, the system won’t be aware of the user’s preferences for the app language and thus it will map the app to the default system language. To avoid this, developers need to add some one-time migration logic so that their users don’t have to set the language again when they update the app.

// Specify the constants to be used in the below 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 method to put a string in a SharedPreference
private fun putString(key: String, value: String) {
val editor = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE).edit()
editor.putString(key, value)
editor.apply()
}

// Utility method to get a string from a SharedPreference
private fun getString(key: String): String? {
val preference = getSharedPreferences(PREFERENCE_NAME, PREFERENCE_MODE)
return preference.getString(key, null)
}

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

   // Fetch the selected language from wherever it was stored. In this case it’s SharedPref
   // In this case let’s assume that it was stored in a key named SELECTED_LANGUAGE
getString(SELECTED_LANGUAGE)?.let { it →

      // Set this locale using the AndroidX library that will handle the storage itself
val localeList = LocaleListCompat.forLanguageTags(it)
AppCompatDelegate.setApplicationLocales(localeList)

      // Set the migration flag to ensure that this is executed only once
putString(FIRST_TIME_MIGRATION, STATUS_DONE)
}
}

What flexibility does the feature provide to the users and developers?

Here are a few things that might prove to be beneficial for you users.

All devices running Android 13 or higher will have a common place for users to discover and change the language of their apps.
Although the system settings are limited to the devices running Android 13 or higher, the AndroidX APIs are backwards compatible. Thus, there is no requirement to add OS Version checks in your code while building for your multilingual users.
Developers do not need to handle configuration changes separately or worry about storing the user's selected language every time. The API handles configuration changes and stores the language preferences for you.
Works with other Android features like Backup and restore. If a user switches to a new device and restores the previously backed up data, your app will retain the user’s last preferred language, thus providing your users with a better and more seamless experience.

Recap

With that, most parts of the feature are covered. So let’s have a quick recap on what we discussed in today’s read.

A quick read on what Per-App Language Preferences offer to multilingual users and app developers.
What end users will see on their devices.
How to migrate your app to the Per-App Language Preferences APIs.
A few things that need to be taken care of while migrating to the APIs to ensure a better user experience.
Lastly, the benefits that end users and developers can leverage from this feature.

References

Source: Android Developers Blog

Workspace Admins are now notified when Label editing is restricted by set rules

What’s changing

In addition to a recent feature allowing admins to programmatically manage and apply Drive Labels using new API functionality, we’ve added a new Label Manager UI feature showing which rules a label is used within.

When labels are published, their semantic meaning can be leveraged for the enforcement of rules, such as a DLP policy based on the presence of a label. Labels are locked to prevent the possibility of breaking a related rule, and to make it easier to use labels to enforce rules, we've added warnings and feedback to the Labels Manager UI.

Specifically, a message identifying and linking the label to the exact rule(s) will now appear in the Label Manager to ensure admins understand why label modification is disabled.

Label locking prevents admins from inadvertently renaming, deleting, or disabling a Label, which could result in policy breakage.

Getting started

Admins: Drive Labels must be turned ON for your organization to use this feature. Visit the Help Center to learn more about managing Drive Labels. Once labels are enabled for your organization, Developers can head over to the API Documentation to get started.
End users: There is no end user setting for this feature.

Rollout pace

Rapid Release and Scheduled Release domains: Gradual rollout (up to 15 days for feature visibility) starting on October 17, 2022

Availability

Available to Google Workspace Essentials, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Plus, Education Standard customers
Not available to Business Starter, Education Fundamentals, the Teaching and Learning Upgrade, Nonprofits, and Frontline, as well as legacy G Suite Basic and Business customers
Not available to users with personal Google Accounts

Resources

Google Workspace Admin Help: Manage Drive Labels

Source: Google Workspace Updates

Google Workspace Updates Weekly Recap – September 9, 2022

New updates

Unless otherwise indicated, the features below are fully launched or in the process of rolling out (rollouts should take no more than 15 business days to complete), launching to both Rapid and Scheduled Release at the same time (if not, each stage of rollout should take no more than 15 business days to complete), and available to all Google Workspace and G Suite customers.

Dual pane view on Keep
In addition to Drag out from Keep and a number of other features supporting the mission to provide a top-class user experience on large screen devices, we’re introducing Dual pane view on Keep. This allows you to browse Keep notes on the left side of your screen, while editing content on the right side of your screen. | Roll out to Rapid Release and Scheduled Release domains began September 8, 2022 at a Gradual pace (up to 15 days for feature visibility). | Learn more.

Multi-instance support on Docs, Sheets & Slides
Get better insight into your files by having two windows open side-by-side. | Roll out to Rapid Release and Scheduled Release domains began September 7, 2022 at a Gradual pace (up to 15 days for feature visibility). | Learn more.

View information about recipients on Android
While using the Gmail app on Android devices, you can now view details about a person, such as their phone number or email address, by tapping their name or avatar when composing an email. | This is now available to all users.

Upon tapping Elisa's image or name, more information will appear

Keep contacts up to date with fewer clicks
You can now edit someone’s contact information from their information card in apps like Gmail, Calendar, Voice, and Docs on your Android device. Upon clicking the edit button, you will be prompted to make updates in the Contacts app. | Roll out to Rapid Release and Scheduled Release domains began September 7, 2022 at an Extended rollout (potentially longer than 15 days for feature visibility).

Notification permission now required for devices running Android 13
Upon upgrading to the latest platform release, Android 13, you will have to explicitly accept notification permissions to receive Chat notifications. | Roll out to all Android users began September 9, 2022 at a Gradual pace (up to 15 days for feature visibility). | Learn more.

Previous announcements

The announcements below were published on the Workspace Updates blog earlier this week. Please refer to the original blog posts for complete details.

Calendar User Availability API launching to beta soon, sign-up now and preview documentation in advance
There is an upcoming beta available for the Calendar User Availability API that can be used to programmatically access the working location feature in Google Calendar. Access the beta through the Google Workspace Developer Preview Program. | While all developers will be able to use the API, apps created using the API are accessible to Google Workspace Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Education Fundamentals, Education Plus, Education Standard, the Teaching and Learning Upgrade and Nonprofits customers, as well as legacy G Suite Business customers only. | Learn more.

Scaling our Calendar Interop offering
Admins can now configure multiple role accounts in the Calendar Interop Admin console. This will provide support for a higher number of requests and enable Calendar Interop to work more seamlessly at scale. | Learn more.

Updating framing options for Google Meet hardware in the Admin console
Over the coming weeks, we will replace the current continuous framing setting with the option to set default framing options based on the camera capabilities of the device — such as the option to frame people by default and speaker or group framing, which will be introduced in the future. | Available for all supported Google Meet hardware devices that have not yet reached their auto-update expiration date. | Learn more.

For a recap of announcements in the past six months, check out What’s new in Google Workspace (recent releases).

Source: Google Workspace Updates