Home / Blog / Guides
Guides

Android Localization Guide: strings.xml to Play Store

Everything you need to localize an Android app: strings.xml and resource folders, placeholders and plurals, RTL layouts, per-app language settings, translation workflow and the Play Store listing.

WordBeam Team
Aug 07, 2024 · 6 min read
Android Localization Guide: strings.xml to Play Store

Android runs on billions of devices worldwide, and most of those users do not speak English as their first language. Localizing your Android app is one of the most direct ways to grow installs and ratings in new markets. The good news is that Android has a solid built-in system for it. This guide covers the full path, from strings.xml to a localized Play Store listing.

How Android Localization Works

Android loads text and other resources from folders named by locale. The default strings live in res/values/strings.xml. Translations go into folders such as res/values-de/, res/values-fr/ or res/values-pt-rBR/ for Brazilian Portuguese. At runtime, the system picks the best match for the user's language settings and falls back to the default folder when a string is missing. The official Android localization guide explains the resolution rules in detail.

Step 1: Move Every String Into Resources

Hard-coded text in layouts or Kotlin code cannot be translated. Android Studio's lint warnings help you find it. Move all user-facing text into strings.xml with clear names, for example checkout_pay_button, and add a short comment for translators where the meaning is not obvious.

Step 2: Use Placeholders and Plurals Correctly

  • Placeholders. Use numbered format arguments such as %1$s and %2$d so translators can change word order.
  • Plurals. Use the <plurals> resource with quantities such as one, few, many and other, and read it with getQuantityString. Never build plurals with if statements in code.
  • Non-translatable text. Mark brand names or technical values with translatable="false" so they are not sent for translation.

Step 3: Design for Text Expansion and RTL

Translated text can be much longer than English. Use ConstraintLayout or flexible layouts, avoid fixed widths and let text wrap. For Arabic, Hebrew and other right-to-left languages, enable android:supportsRtl="true" and use start and end instead of left and right so layouts mirror automatically.

Step 4: Format Dates, Numbers and Currencies by Locale

Use locale-aware formatting classes rather than building strings by hand. A price, a date or a decimal number should look natural in every market without extra work from translators.

Step 5: Offer Per-App Language Settings

Since Android 13, users can choose a different language for each app in system settings. Declare your supported languages in a locales_config file and reference it in the manifest so your app appears in that list. For older versions, AndroidX AppCompat provides a backward-compatible API.

Step 6: Translate and Keep Strings in Sync

The hardest part of Android localization is not the first translation but every release after it. New strings appear in each sprint, and translations must follow. A good workflow:

  1. Export new and changed strings from the default strings.xml.
  2. Translate them in a CAT environment with translation memory and a glossary, so repeated phrases stay consistent across screens.
  3. Run automated checks on format arguments and plural forms.
  4. Import translations into the matching values-xx folders and build.
  5. Test on devices in each language before release.

Many teams convert Android resources to a standard exchange format such as XLIFF or JSON for this step, which makes it easy to use with any TMS. Connecting the process to your repository turns it into continuous localization.

Step 7: Localize the Play Store Listing

Users decide whether to install before they open your app. In Play Console you can add translated titles, short and full descriptions, screenshots and feature graphics for each language. Research local keywords for the listing rather than translating the English one word for word, and use screenshots that show the app in that language.

Common Android Localization Mistakes

  • Concatenating strings in code instead of using format arguments.
  • Missing plural forms for languages with more than two categories.
  • Forgetting notifications, widgets and error messages.
  • Translating the app but leaving the store listing in English.
  • No fallback testing, so missing strings show up in the wrong language.

How WordBeam Helps Android Teams

WordBeam gives Android teams one place to translate app strings with translation memory, term bases and AI pre-translation from DeepL, GPT, Claude or Grok. Placeholder checks protect format arguments, reviewers work in context, and on the Studio plan GitHub and GitLab integrations keep translations in sync with your code. See how it supports software localization and UI translations.

Frequently Asked Questions

Where do translated strings go in Android?

In res/values-xx/strings.xml, where xx is the language code, optionally with a region, such as values-es-rMX.

What happens if a translation is missing?

Android falls back to the default res/values/strings.xml, so users see the source language for that string.

Should I localize the Play Store listing too?

Yes. A localized listing with local keywords and screenshots often has a bigger effect on installs than the in-app translation alone.