How we made 17 in-app languages actually work in Googly Player on Android

You translate an Android app into a dozen languages, add a language picker to the settings screen, test it on your own phone, and ship. Then someone chooses Arabic and the whole app stays in English. There is no crash and nothing in the logs. Or the app does switch, but a count reads with the number stuck on the wrong side of its label, and the notification that keeps playback running still arrives in the phone's system language.

None of these problems shows up when you test in your own language, which is why they reach users. Each one comes from a specific decision in how translations are packaged, applied, laid out and formatted, and each one has a specific fix.

We hit all of them building Googly Player, our Android app for videos, music and photos. It ships with a full in-app picker for 17 languages that works independently of the system language. This is how we built it, decision by decision -- useful if you are planning the same work, or deciding whether to have us do it for you.

Seventeen languages, chosen inside the app

Googly Player lets the user pick the app's language directly, whatever the phone itself is set to. Someone whose device runs in English but who would rather read in Bengali or Turkish can make that choice in the app without touching the rest of the phone. These are the languages it ships with:

The list spans Latin, Devanagari, Arabic, Bengali, Cyrillic, Japanese, Korean and Gujarati scripts, and two of the languages -- Arabic and Urdu -- run right to left. That mix is what turns language support from a translation job into an engineering one: text direction, font coverage, number placement and grammar rules all vary across it, and the app has to get each right without anyone on the team reading every language.

A picker built so people can find their own language

Every language in the picker is listed by its endonym -- its own name in its own script -- as the main label, with the English name underneath. The reasoning is simple: a person looking for their language recognises Русский or ગુજરાતી faster than the English word for it, and someone who has accidentally switched the app into a language they cannot read still needs to find their way back. The English name underneath serves everyone else.

The picker is searchable, and it opens with a Suggested section based on the device locale, so the most likely choice sits at the top rather than somewhere in a list of seventeen. Search and suggestions together mean nobody has to scroll past scripts they do not read to reach the one they do.

Right to left, all the way down

Arabic and Urdu get full right-to-left support. Mirroring the main screens is the obvious part; the less obvious part is everywhere a right-to-left language meets left-to-right content. The language picker is the sharpest example. In an Arabic or Urdu session it lists names written in Latin, Cyrillic, Devanagari, Japanese and other scripts alongside Arabic-script names, and each of those has to sit where a reader expects it rather than drifting to the wrong edge of its row.

We anchor the language names in the picker correctly in right-to-left mode, so the list reads as a clean column in either direction. It is a small detail, but it is the first screen a right-to-left reader sees after making their choice, and a picker that misaligns its own entries tells them straight away how much care went into the rest.

One setting for the whole process

The chosen language is applied process-wide through AppCompatDelegate.setApplicationLocales. That matters in a media player more than in most apps. Googly Player keeps playing in the background through a foreground service and shows a media notification while it does, so a locale switch that only reached activities would leave the notification, the service behind it and any dialog speaking the old language. Applying it to the whole process covers services, notifications and dialogs, not just activities.

On Android 13 and later, the choice is handed to the platform. The same setting then appears under Settings › Apps › Googly Player › Language, so a user can change the app's language from the system as well as from inside the app, and both places stay in agreement.

The bug that leaves no trace: language splits

This is the one that catches teams who have done everything else right. When an app is published as an App Bundle with language splits enabled, Google Play delivers only the resources for the device's system language. That is sensible for an app that follows the system language. For an app with its own picker it is a trap: the other sixteen translations never reach the device, so choosing one of them changes nothing visible.

The failure is silent. The picker renders everything in English, there is no crash, and nothing appears in the logs, because from Android's point of view the app asked for a language whose resources simply are not installed and fell back as designed. Testing on a developer's phone does not catch it either, since builds installed directly from a development machine are not split the way Play splits them.

We deliberately disable language splits in the App Bundle, so every translation ships in the base APK and every language in the picker is available on every device.

Numbers belong inside the sentence

Counts in Googly Player are formatted, never concatenated. A string like "Total Videos: %d" lets each translation decide where the number goes. Building the same text as "Total Videos: " + n fixes the number to the end of the string in code, and in Arabic and Urdu that puts it on the wrong side of the label.

Concatenation is the habit most codebases pick up early, because it works in English and reads naturally to the person writing it. The cost appears only once a right-to-left translation lands, at which point every concatenated count has to be found and rewritten. Using format strings from the start means a translator can place the number where their language needs it, and the code never has to know.

Plurals that follow the grammar

Placing the number correctly is half the job; the words around it also have to agree with it. English gets by with very little here, which hides the problem. Arabic needs six grammatical forms for a number and Russian needs four, and no single format string can express that, however carefully it is written.

Googly Player uses proper Android plural resources, so each translation supplies every form its language needs and the system picks the right one for the count at runtime. The result is that a phrase with a number in it reads as correct grammar in Arabic and Russian rather than as a stilted compromise, and adding another language later means adding its forms, not rewriting code.

What it runs on and how to set a language

Googly Player is an Android app, distributed through Google Play as an App Bundle with every translation in the base APK. The in-app picker works independently of the system language, and the system-level language setting is available on Android 13 and later. Changing the language takes a few taps:

1. Open the language picker

   The full in-app picker lists all 17 languages, each by its own name with the English name underneath.

2. Search, or start from Suggested

   Type to filter the list, or pick from the Suggested section, which is based on your device locale.

3. Choose your language

   It applies across the whole app, including the playback notification and dialogs. Arabic and Urdu switch the layout to right to left.

4. Or set it from Android settings

   On Android 13 and later, the same choice is available under Settings › Apps › Googly Player › Language.

If you are building an Android app that needs its own language picker, these are the decisions we would make with you on day one rather than discover after launch: process-wide locale application, no language splits, right-to-left layout including mixed-script lists, format strings for every count and plural resources for every phrase with a number in it.

Questions