
Launching an app in a new market often starts with an optimistic plan. Export the strings, send them to translators, import the results, ship. Two releases later, the German version has truncated buttons, the Russian onboarding screen still shows English placeholders, and the support team is answering tickets about a confusing payment message nobody reviewed.
Localisation works best when it is treated as part of product development, not as a task at the end of it.
Before any translation happens, the code must be ready for other languages. This preparation, known as internationalisation, includes separating text from code, supporting Unicode, allowing for longer strings, handling plural forms and formatting dates, numbers and currencies according to locale. The overview of internationalisation and localisation on Wikipedia summarises the main principles.
Fixing internationalisation issues after launch is far more expensive than getting them right early. A quick audit before the first translation round saves weeks later.
A single word such as "Save", "Open" or "Share" can be translated differently depending on where it appears. Is "Book" a noun or a verb? Is "Free" about price or availability? Translators working from a spreadsheet of isolated strings have to guess.
Provide screenshots, descriptions and character limits for each string. Many teams now use in-context previews, where translators see the actual screen while they work. The result is fewer errors and fewer rounds of bug fixing.
German and Russian texts are often 20 to 35 percent longer than English. Finnish, French and Polish can also run long. Buttons, menus and notifications that fit perfectly in English may overflow in other languages. Designers should leave room for expansion and test layouts with long strings early.
Many teams rely on a translation from english to russian as a stress test during design reviews, since Russian combines long words, complex grammar and a different alphabet, revealing layout problems quickly.
Manual file exchanges do not scale. Each release adds new strings, changes existing ones and deletes others. Keeping every language in sync by hand becomes impossible after a few updates.
A translation content management system connected to the code repository solves this. New and changed strings are detected automatically, sent to translators, reviewed and pushed back as part of the build. Translation memory ensures that previously approved text is reused, keeping terminology consistent across releases.
Terms of service, privacy notices, consent dialogs and payment messages carry legal weight. These should never be left to machine translation or rushed at the last minute. For European markets, German-language legal text deserves special care, and companies headquartered in Germany often work the other way too, relying on professional german to english translation services to prepare English versions of their policies for global users.
The app store page is often the first impression in a new market. Titles, subtitles, descriptions, keywords and screenshots all need localisation. Keyword research in each language helps the app appear in local searches. Screenshots with text should be recreated in each language rather than left in English.
Linguistic quality assurance on the running app catches problems that no spreadsheet review can find: truncation, wrong gender agreement, awkward line breaks, inconsistent terminology between screens and untranslated error messages. Native testers should go through key user journeys, such as onboarding, payment and support, in every language.
Once live, users will send feedback, reviews and support requests in their languages. Prepare templates, localised help articles and a process for routing translation issues back to the localisation team. User feedback is one of the best sources of quality improvements.
Track conversion rates, retention and ratings by language. If one market performs noticeably worse, localisation quality may be part of the reason. Small improvements in onboarding text or payment messages can have a measurable impact on revenue.
Machine translation can speed up low-risk content such as release notes or internal documentation, especially when followed by human post-editing. For user interface text, marketing copy and anything legal, human translators remain the safer option. The best teams define clear rules about which content type goes through which process.
Clear ownership also helps. When one person on the product team is responsible for localisation quality, issues are fixed faster and decisions about new languages are made with real data rather than guesswork.
Products that feel native in every language earn more trust, better reviews and stronger growth. Teams that build localisation into their everyday workflow, rather than treating it as a one-off project, ship faster in new markets and spend far less time fixing avoidable mistakes after launch.