- Keep every piece of app text in string catalogs or resource files from the first release, never hard-coded in screens.
- Text sent by your server, such as push notifications and emails, needs translating too, so the back end must know each user's language.
- Use the platform's plural and formatting tools; languages count, write dates and show numbers differently.
- Right-to-left languages need mirrored layouts and checked icons, not just translated words.
- Translate the App Store and Google Play listings, and test every language on a device before release.
What does it take to translate a mobile app properly?
Keep all app text in the platform's string files from the first release, translate what your server sends as well as what the app shows, use the built-in tools for plurals, dates and numbers, mirror the layout for right-to-left languages, translate the store listings, and test each language on a device. Translating the words is the smallest part of the job.
Apps that planned for this can add a language without touching their screens; apps that did not often need screens reworked first. It is part of how our mobile app development team structures an app from the start.
Which parts of an app need translating?
- Screens: labels, buttons, onboarding, empty states and error messages.
- Text from your server: push notifications, emails, SMS messages, receipts and error messages returned by the API.
- Images with words in them, including illustrations and screenshots used inside the app.
- The store listings: name, subtitle, description, keywords and screenshots on the App Store and Google Play.
- Help content and support, or at least a clear note about which languages support answers in.
Server-sent text is the part most often forgotten. The back end needs to store each user's language and choose the right template when it sends anything, which is one of the items in our mobile app back-end checklist.
How should app text be set up for translation?
Never hard-code text in screens. On iOS, Xcode's string catalogs collect localizable text in one place: building the app adds the strings it finds to the catalog automatically, and from there you add languages, translations, comments for translators and plural or device variants.
On Android, text lives in resource files, and the default file matters more than people expect. For any language you have not translated, Android loads the default res/values/strings.xml, and if a needed string is missing from it, the app doesn't run on a device set to that language. Keep the default file complete and treat a missing string as a build error.
Two habits make translators' work much easier: write full sentences with placeholders instead of joining fragments in code, since word order changes between languages, and add a short comment where a word could mean two things, such as "Book" as a noun or a verb.
Why do plurals, dates and numbers need special handling?
English has two forms, "1 book" and "2 books", so adding an "s" in code seems to work until you add another language. Android supports the categories zero, one, two, few, many and other, and provides methods that pick the right form for each language and number. Apple's string catalogs support plural variants per language in the same way.
Dates, times, numbers and currencies also differ by locale: the order of day and month, the decimal separator, the currency symbol's position. Use the platform's formatters with the user's locale instead of fixed formats. Prices are a business decision as well as a display one: decide whether each market gets its own price before you translate the paywall.
What changes for right-to-left languages?
Readers of Arabic and Hebrew expect the interface to be mirrored: navigation from the right, text aligned right, and arrows reversed. On iOS, system components flip automatically in a right-to-left context, so standard layouts need little work; custom layouts and icons need checking. Apple also notes that the digits within a number are never reversed, while progress indicators that show a direction are.
On Android, set android:supportsRtl in the manifest and use start and end instead of left and right in layouts; automatic mirroring works on Android 4.2 (API level 17) and higher. Apple's guidance is to flip icons that show forward or backward motion or reading direction, but never flip logos or universal signs and marks. These are design decisions for our UI and UX design team before they are code.
How do users choose the app's language?
By default an app follows the device language when it includes that language. People who use several languages can also choose a different language for one app: on iOS and iPadOS independently of the device, and on Android in system settings since Android 13. If you build your own language picker inside the app, use the Android per-app language APIs, which sync with system settings, so the two choices never disagree.
How do you translate the store listings?
On the App Store, countries where you have not added a localization show your primary language. Keywords you add for a language are used for search in the countries where the App Store supports it. When you add a language, screenshots and other properties are copied from the primary language, except the description and keywords, which you write fresh, as App Store Connect's help explains.
In Google Play Console you can add your own translations, buy translations of the listing and in-app products from as little as USD 0.07 per word, or use machine translations for some languages, which Google says are not reviewed by humans. Play Console can also translate app strings with Gemini at no cost. Screenshots with text need redoing for each language; our publishing checklist covers the rest of each listing.
How do you test a translated app before release?
- Run each language from Xcode. The Run scheme has App Language and App Region options, so you can test a language without changing the device settings for the whole system.
- Use Android pseudolocales. English (XA) adds accents and extra text to expose cut-off labels, and AR (XB) switches text to right-to-left. They need Android 4.3 (API level 18) or higher, developer options turned on, and pseudolocales enabled in the debug build.
- Review screenshots of every screen with a fluent speaker, in context, before the release goes to the stores.
Once the new language is live, read its reviews closely for a few weeks; our guide to app ratings and reviews covers replying well.
Frequently asked questions
Can we use machine translation for the app?
As a first draft, yes. Play Console can translate app strings with Gemini and offers machine translations of store listings, which Google says are not reviewed by humans. Have a fluent speaker check every screen in context, because a word that is correct on its own can be wrong on a button, and use a professional for payment and legal text.
Do we have to translate the whole app at once?
Translate complete journeys rather than random screens: onboarding, sign-in, the main task, payments, settings and error messages. A screen that mixes two languages looks broken. If a string is missing in a translation, the app shows the default language for it, so missing text is easy to spot during testing.
Which languages should we add first?
Start with the evidence you already have: the countries your installs and website visitors come from, the languages support requests arrive in, and the markets your sales team is targeting. One language done well, including the store listing and support, is worth more than several that are half finished.
Does a translated store listing help people find the app?
Yes. On the App Store, keywords you add for a language are used for search in the countries where the App Store supports that language, and countries without your language show your primary language instead. A translated listing also tells people before they download that the app speaks their language.
What does localization add to the cost of an app?
Very little if text is kept in string files from the first release, and a lot if it has to be pulled out of finished screens later. Right-to-left support adds design and testing work on every screen, so decide early whether you need it. Translation and review costs depend on the amount of text and the languages.
Last updated