17 languages, one picker: how Googly Player keeps its translations from failing silently

An in-app language picker looks like the easy part of localisation: translate the strings, add a list, save the choice. The hard part is everything that happens after the list. A picker can work perfectly on a developer's phone and then, once the app is installed from the store, show every screen in English with no crash and nothing in the logs. Nobody reports it, because nothing visibly broke.

The quieter failures are just as common. The screens switch language but the notification from a background service does not. A count reads correctly in English and lands on the wrong side of its label in Arabic. A Russian or Arabic number shows the wrong grammatical form, because a single format string cannot express four or six plural forms.

Googly Player, our app for videos, music and photos on Android, ships in 17 languages chosen from inside the app, independent of the phone's own language. This is how we built that picker so that what a person chooses is what they actually see, everywhere the app speaks to them.

Seventeen languages, picked inside the app

Googly Player has a full in-app language picker that does not depend on the language the phone itself is set to. Someone whose device runs in English can use the app in Bengali, Turkish or Japanese, and switch again later without touching their system settings. These are the languages it ships with, and the name each one carries in the picker:

The list covers seven scripts, two of which run right to left. That mix is what drives most of the engineering described below: a set of languages that all shared Latin script and left-to-right layout would hide most of these problems until much later.

Names written the way their speakers write them

Every language in the picker is listed by its endonym, its own name in its own script, as the main label. The English name sits underneath. Someone looking for Gujarati is scanning for ગુજરાતી, not for an English word they may not read comfortably, and someone helping them set up the phone can still find it by its English name.

The list is searchable, and a Suggested section at the top is built from the device locale, so the most likely choices are the first ones offered. For Arabic and Urdu the language names are correctly anchored for right-to-left text inside the picker itself. A list where اردو is pushed to the wrong edge, or where its English label fights it for alignment, is the first sign to a reader that the translation behind it will be careless too.

One setting for the whole app

The usual shortcut for an in-app language switch is to override the locale on each screen. That covers what the user is looking at and misses everything else. Googly Player plays media in the background, so a large part of what people read comes from places that are not screens at all: the media notification, a dialog raised while something is playing, text produced by a service.

We apply the chosen language process-wide through AppCompatDelegate.setApplicationLocales. Because it acts on the whole process rather than on individual activities, the same choice reaches services, notifications and dialogs. A person who picks Korean gets Korean in the notification shade as well as in the library, which is the only version of the feature that matches what they asked for.

On Android 13 and later, the platform holds the choice

From Android 13 onward, Googly Player hands the language choice to the platform instead of keeping it as a private setting. The practical result for the user is that the language they picked inside the app also appears in system Settings, under Settings › Apps › Googly Player › Language, and can be changed from either place.

That matters for anyone who manages a phone for someone else. If a relative set the app to Urdu and you need to check or change it, you can do it from the same system screen where Android lists per-app languages, without first finding the picker inside our menus. On earlier Android versions the choice still applies across the whole app; it simply lives inside the app rather than in system Settings.

The failure that leaves no trace

Googly Player is built as an Android App Bundle, and by default an App Bundle lets Google Play split resources by language. Play then installs only the strings for the device's system language. For most apps that is a sensible saving. For an app with its own language picker it is a trap: the picker offers 17 languages, but only one set of translations is actually on the phone.

When someone chooses a language whose resources were never delivered, Android falls back to the defaults. The picker renders everything in English. There is no crash and nothing in the logs, and on a developer's machine, where the full set of resources is installed, the bug does not exist. We deliberately disable language splits in the bundle so that every translation ships in the base APK, and the language a person picks is always one the app can show.

Numbers on the correct side of the label

Arabic and Urdu are written right to left, and Googly Player supports them fully, including the language names in the picker. Layout mirroring gets most of the attention, but the bug people actually notice is smaller: a number sitting on the wrong side of its label.

That happens when a string is assembled by concatenation, such as "Total Videos: " + n. The code fixes the order as label then number, which is right for English and wrong for a right-to-left language. We format counts instead of concatenating them, using a string like "Total Videos: %d". The whole phrase, placeholder included, goes to the translator, and each translation puts the number where its own language expects it.

Plural forms that a format string cannot express

A format string fixes word order; it does not fix grammar. English needs two forms for a count, one and many. Arabic needs six grammatical forms for a number and Russian needs four, so a sentence such as a count of videos has to change its wording depending on the number itself, not just slot the number in.

We use Android's plural resources for every count that needs them. Each language supplies as many forms as its grammar requires, and the platform picks the right one for the number at runtime. The alternative, an if for one and an else for everything else, produces text that is wrong most of the time in exactly the languages where readers are most used to apps getting it wrong.

What it takes to do this in an Android app

For anyone using Googly Player, the requirements are simple: it runs on Android, the language picker is inside the app, and on Android 13 or later the same choice also appears in system Settings under the app's Language entry. Arabic and Urdu users get right-to-left layout throughout.

For a team building its own picker, these are the steps we follow, and the order we would check them in on someone else's app:

1. List languages by their own names

   Show each language's endonym as the main label with the English name underneath, make the list searchable, and add a Suggested section from the device locale.

2. Apply the locale process-wide

   Use AppCompatDelegate.setApplicationLocales so services, notifications and dialogs follow the choice, not only activities. On Android 13 and later this also hands the choice to the platform.

3. Turn off language splits

   Disable language splits in the App Bundle so every translation ships in the base APK. Test with a build installed from Play, where this failure shows, not only a local build.

4. Format counts, never concatenate

   Pass numbers through format strings so each translation decides where the number sits, which keeps Arabic and Urdu correct.

5. Use plural resources

   Give every count a plural resource so Arabic can supply its six forms and Russian its four.

6. Check right-to-left in full

   Run the app in Arabic and Urdu and confirm text, layout and the picker's own language names are anchored correctly.

Questions