Most mobile apps launch in one language. Then the download numbers come in from Brazil, Germany, Japan or Turkey, and someone in a planning meeting says the obvious thing: we should translate this. A few months later, the team is juggling spreadsheets of strings, broken layouts in German and a release delayed because the Japanese translation is not back yet.
It does not have to be that way. Teams that treat localisation as part of the development pipeline, rather than a separate project, ship multilingual apps almost as fast as single-language ones.
Start with internationalisation
Localisation is only as good as the code underneath it. Internationalisation, often shortened to i18n, means preparing your app so it can be adapted to different languages and regions without changing the code each time.
The basics are well documented. Android's localisation guide and Apple's equivalent for iOS explain how to externalise strings into resource files, handle plurals and format dates, numbers and currencies by locale. Key principles include:
- Never hard-code user-facing text in the source code.
- Use placeholders instead of concatenating strings, since word order changes between languages.
- Support plural rules properly. Polish and Arabic have several plural forms, not just one and many.
- Design layouts that can expand. German text is often 30 per cent longer than English.
- Plan for right-to-left languages such as Arabic and Hebrew from the start.
Give translators context
A string like "Back" could mean a navigation button, a body part or the reverse side of a card. Without context, translators guess, and guesses produce bugs. Good teams add comments to their resource files, share screenshots and describe where each string appears.
Character limits matter too. A button that fits "Save" will not fit "Speichern" or "Enregistrer" unless the design allows it. Telling translators about limits up front avoids truncated text in production.
Automate the string flow
The biggest time sink in app localisation is moving text around. Developers export strings, someone emails them to translators, files come back with formatting errors, and someone else imports them again. Every manual step is a chance for mistakes.
A TMS translation management system removes most of this friction. It connects directly to your code repository, detects new or changed strings, sends them to translators and pushes approved translations back as a pull request. Many teams set it up so that every merge to the main branch triggers a sync.
The goal is simple: no developer should ever have to copy and paste a translation.
Teams that want an end-to-end workflow rather than isolated tooling often turn to dedicated localization services that cover testing, store-listing adaptation and regional QA alongside translation. That broader remit catches the locale bugs and culturally tone-deaf screens that slip through when each stage is handled by a different vendor. For app teams, it means fewer surprises at release time and a faster path to each new market.
How translators work
On the translation side, professionals use a CAT editor, short for computer-assisted translation. It shows each string with its context, flags placeholders that must not be changed, checks length limits and lets reviewers comment. Translators can work in the browser while the system handles file formats such as XML, JSON, XLIFF or Apple's strings files.
Reuse what you already translated
Apps repeat themselves. "Cancel", "Try again", "Something went wrong" and "Your password must contain at least eight characters" appear in dozens of places and across several products. Memory translation software stores every approved translation and offers it automatically the next time the same or a similar string appears. That cuts costs, speeds up delivery and keeps terminology consistent across the app, the website and support articles.
Machine translation with human review
Modern machine translation is good enough to produce useful first drafts for many language pairs. Many teams now use it for low-risk content such as internal tools or beta features, then have professional linguists post-edit the output before public release. For legal text, payment flows and onboarding, human translation from the start is usually the safer choice.
Test in every language
Localisation bugs are real bugs. Common ones include text overflowing buttons, untranslated strings slipping through, wrong date formats and broken layouts in right-to-left languages. Automated screenshot testing across locales catches many of these. Pseudo-localisation, where the app is filled with artificially long, accented text, reveals layout problems before translation even starts.
Native speakers should still review key screens. A translation can be technically correct and still feel awkward or overly formal to real users.
Do not forget the store listing
Translating the app is only half the job. App Store and Google Play listings, including the title, description, keywords and screenshots, drive downloads in each market. Localised screenshots with translated captions often improve conversion rates noticeably. Review responses and push notifications deserve the same care.
A realistic workflow
- Developers add new strings with context comments.
- The TMS picks them up automatically on merge.
- Translation memory and machine translation pre-fill what they can.
- Professional translators complete and review the rest.
- Approved translations are pushed back to the repository.
- Automated tests check layouts in every locale before release.
The payoff
Apps available in the user's own language consistently see higher downloads, better ratings and stronger retention. With the right setup, adding a new language becomes a matter of days rather than months. Localisation stops being a bottleneck and becomes just another part of shipping good software.
