Mobile app localisation includes language, layout, dates, numbers, search and support content. Translating visible labels is only one part. Define the supported locales, fallback behaviour and review process before estimating the work, then test complete journeys with representative content rather than short placeholder strings.
Let’s plan your app language coverage.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Inventory content outside the main screens
Include notifications, validation errors, emails, help articles, store descriptions and generated documents. Identify text supplied by the server and third-party services. A translated interface can still fail its users if the first important error appears in an unsupported language.
Use a terminology list for business concepts. In a hypothetical service app, request, booking and appointment might describe different records. Review their translations with people who understand the actual workflow, not only individual words.
Build a locale acceptance matrix
| Area | Decision to document | Test example |
|---|---|---|
| Language choice | Device default and explicit override | Change language without losing a draft |
| Missing content | Supported fallback | Untranslated server message |
| Layout | Expansion and text direction | Long labels and large text |
| Dates and time | Display locale and time zone | Booking near a day boundary |
| Numbers | Decimal, grouping and currency meaning | Enter and review a monetary amount |
| Search | Script, spelling and mixed-language input | Find the same authorised record |
These cases define product acceptance, not a claim that every locale shares the same formatting conventions. Obtain examples from the intended markets and validate them with reviewers.
Preserve meaning in stored data
Separate a record's underlying identifier from its translated display label. Changing a language should not create a different business state. Similarly, a formatted date string should not be the only information needed to interpret an appointment time.
Clarify which user-entered content is translated, if any. Automatic translation can alter business meaning; show the original where the task requires it and define an appropriate review path. Do not imply that localising navigation translates documents or customer messages automatically.
Make localisation maintainable
Assign ownership for new strings, translation review and release sign-off. Keep content changes traceable so the team knows which translations became stale after an English revision. Include actual translated builds in the test cycle.
Avoid judging completeness only by the percentage of translated keys. A missing confirmation message can matter more than several unused settings labels. Prioritise complete supported journeys and tell users where language coverage ends.
Localisation questions
Can we add languages after the first release?
Yes, but plan content separation and layout flexibility early. Retrofitting text embedded in images or business logic creates avoidable work.
Is a bilingual reviewer enough for acceptance?
Language review is necessary, while device interaction, formatting and workflow checks also need testing in the delivered app.
Include locale coverage in the device testing matrix and discuss the content inventory with Drema's mobile app team.
