Mobile app localization adapts the product for people in a particular language and region. Translation is one part; the full job includes interface layout, plural forms, dates, currencies, content, support, and testing. Internationalization is the engineering foundation that makes these variations possible.
This guide covers the implementation inside your app. For the separate work of translating titles, descriptions, and screenshots, use the store listing localization workflow. Check both so the translated store page matches what people will find in the app.
1. Define a supported user journey
Choose one locale and a complete task: onboarding through a saved note, a completed workout, or a successful purchase. Identify every screen, message, email, and help link encountered during that task. Include errors and empty states; people need to understand those most when something fails.
Agree on the regional language variant, who will review it and which parts of the app belong in the release. “Spanish” may be too broad for your writing decisions; agree which audience you intend to serve. Start with existing user demand and support capacity, then use the market selection guide to compare expansion options.
2. Externalize complete messages
Move user-facing text into the localization system used by your platform. Preserve stable keys, context comments, placeholders, and the meaning of each message. Avoid composing sentences from independently translated fragments: word order and grammar can change.
Apple's string catalog documentation explains translations and variations in Xcode. Android's localization guide covers localized resources. Use your framework's current conventions rather than copying a file structure that belongs to another stack.
For example, give a translator “{name} completed {count} tasks” with an explanation of each variable and its possible values. Use the platform's plural handling for the count; changing “task” to “tasks” in English is not a universal plural rule. Test zero, one, and other values required by the target language.
3. Make formats and layout locale-aware
Store values in an appropriate structured form, then format them for display. A date is not just a hardcoded string. A currency code identifies the unit of money; a locale controls its presentation. Changing a currency symbol does not convert the amount.
- Use locale-aware number, date, and currency formatters.
- Keep names and addresses flexible instead of assuming every user has the same field structure.
- Allow labels and controls to grow or wrap where the interaction permits it.
- Test truncation and accessibility text sizes on the actual screens.
- Use logical layout direction for RTL languages, and review icons or media that should not mirror.
Translated length depends on the particular phrase, not a fixed percentage for a whole language. Test short labels as well as paragraphs. The difference between “Save” and “Speichern” is an example of why character counts alone do not tell you whether a button fits.
4. Give translators context and boundaries
A glossary should identify terms to preserve, terms to translate, product names, and sensitive claims. Add screenshots and describe the action behind ambiguous labels such as “Open,” “Save,” or “Trial.” Specify whether a string is a button, error, title, or legal message.
AI can prepare drafts, but assess them against the real task rather than an advertised accuracy score. Ask a fluent reviewer to check meaning, terminology, tone, and feature scope. Specialist content may need specialist review. For a realistic estimate of translation, engineering, and recurring costs, see localization budgeting.
5. Test before and after translation
Try pseudolocalization early: it replaces ordinary text with test strings to expose hardcoded labels, clipping and layout problems. Android provides a pseudolocale testing guide. This checks engineering behavior; it does not establish that a translation sounds natural.
| QA layer | What to inspect | Evidence to save |
|---|---|---|
| Structural | Missing keys, invalid placeholders, plural variants | Build/check results |
| Visual | Wrapping, direction, font coverage, captions | Real device captures |
| Linguistic | Meaning, terminology, tone, context | Reviewer decisions |
| Functional | Complete task, permissions, sign-in, payment and recovery | Test case and observed result |
Test fallback behavior when a translation is missing. Include mixed-language content, user-entered names, interrupted network requests, and dynamic values. Make sure people can understand and recover from errors as well as complete the main task.
6. Align the listing with the product
Capture the actual supported locale and create a coherent screenshot set. In AppDrift's screenshot editor, the captions and layouts are editable; the interface inside a screenshot must come from your app. Do not represent English UI as a translated product by only changing the surrounding captions.
Prepare listing copy with metadata translation and review it separately from resource files. AppDrift does not translate your app code or implement RTL support. Keep release notes and language availability accurate.
7. Maintain the supported experience
Assign an owner for changed source strings, new screenshots, and help content. Track translations against the source version so a product update does not silently invalidate prior review. Reuse approved text when the meaning and context are unchanged; review changed claims before reuse.
After release, compare markets where your reporting allows it. Check completed tasks, errors, support questions, return visits and revenue. Low activity may reflect weak demand, acquisition, or the product itself. Avoid interpreting every regional difference as a translation problem.
A locale is ready to expand when the product works, the listing is truthful, someone can maintain it, and the observed customer need justifies the work. For store-side review, Listing updates keeps the next listing version and its decisions together.
Frequently asked questions
What is the difference between translation and app localization?
Translation changes language. App localization also adapts formatting, layout, content, support, and functional behavior for the intended audience.
Should I internationalize before translating?
Yes. Establish resource handling, message variations, locale-aware formatting, and flexible layout before scaling translation. This makes implementation and testing easier to maintain.
What does pseudolocalization test?
It helps reveal hardcoded strings, truncation, direction, and layout problems before real translation. It does not replace native linguistic review.
Does a localized listing mean the app itself is translated?
No. Store metadata and app resource files are separate. Describe the actual supported product languages accurately in your listing.
