A small studio spends nine months building a budgeting app. The code is clean, the design is crisp, and the first reviews at home are warm. Then the team launches in Germany and Brazil, and downloads stall within a week.
The reason is rarely the technology. Most failed global launches fail in the words, not in the code. Here are the mistakes that show up again and again, and how to avoid them.
Hard-coded text inside the interface
The most common technical error is also the cheapest to fix early. When button labels, error messages and menu items live inside the source code, every new language turns into a mini project for a developer.
Move all visible text into resource files from day one. Both major mobile platforms support this out of the box, and Android's localization guide shows the standard approach step by step.
Layouts that assume English length
German words run long. French phrases are often a third longer than their English source. A button that fits "Save" will clip "Speichern" or "Enregistrer" and leave users guessing.
Design with flexible containers, test with the longest language first, and keep at least 30 percent spare room in every label. Right-to-left languages such as Arabic need a mirrored layout, not just translated text.
Strings without context
A translator who sees the single word "Post" has no idea whether it is a noun, a verb or a button. Without context, the result is a guess, and guesses show up as one-star reviews.
Add a short note to every string. Say where it appears, how long it may be and what it does. A screenshot attached to a batch of strings often saves a week of back and forth.
Dates, currencies and units
The date 04/05/2025 means April 5 in the United States and May 4 in most of Europe. Prices use commas and periods in opposite ways. Distance may be miles or kilometres.
Use the formatting tools built into your platform instead of building strings by hand. Let the device locale decide, and test with at least three regions before release.
Machine output with no human check
Automatic translation is fast and good enough for a first draft. It is not good enough for a payment screen or a privacy notice. A mistranslated consent line can trigger a regulator, and an awkward onboarding message can lose a user in ten seconds.
A practical middle path is to let software produce the first pass and have a linguist review everything users will see. If you need a partner for this, an agency offering professional translation services can review app strings, store listings and help pages in one workflow.
Ignoring the store page
Many teams translate the app and forget the listing. Yet the title, subtitle and first screenshots decide whether a stranger installs it. Keywords that work in English rarely map one to one to another language.
Research how people in each market actually search. Localise screenshots too, because an English caption on a Spanish listing signals that the product was not built for them.
No plan for updates
Every release adds new strings, and every new string needs a translation before it ships. Teams without a process end up with half-translated screens, which look worse than a fully English interface.
Set up a simple pipeline. New text is flagged automatically, sent to translators, returned and merged before the build is cut. A translation memory helps here, since repeated phrases cost nothing the second time.
Support content left behind
Help centre articles, email templates and in-app tutorials form the second half of the product. Users who cannot solve a problem in their own language do not write to support. They uninstall.
Start with the ten most visited help topics, translate them first and expand from there. Track which languages generate the most tickets, and invest where the demand is real.
Voice and brand tone
A playful English tone can sound childish in Japanese or too casual in German. Teams that ignore this end up with a product that works but feels strange. Write a short style guide that describes how formal the app should sound in each market.
The piece on multilingual app design goes deeper into how language choices shape the whole product experience.
Examples help translators more than adjectives. Share two or three sample sentences that sound right and two that sound wrong, and ask the team to match that tone. It takes ten minutes and prevents weeks of rewrites later.
A short checklist before you ship
Before any international release, confirm that all text sits in resource files, layouts survive long strings, every string has context, formats follow the local settings, and a human has read the top screens. Add a plan for updates, and you are ahead of most competitors.
Language is not a finishing touch. It is part of the product, and users notice immediately when it is treated that way.
