Mobile App Localization: Where the English Version Breaks
Mobile app localization most often breaks not on string translation, but on assumptions hardcoded into the code. A developer lays out a screen for Russian text, where «Оформить заказ» takes 15 characters, while the English «Proceed to checkout» takes 19.
With a fixed button width or line height, the text gets truncated, the button spills outside the container's bounds, and on small screens the entire grid falls apart.
The same goes for date formats: dd.MM.yyyy in the English version is read as MM/dd/yyyy, and «03.04» turns from the third of April into the fourth of March — in reports, bookings, and reminders this is a critical error.
A separate class of localization problems is declensions and plurals. In Russian, «1 товар, 2 товара, 5 товаров» — three forms, in English — two (1 item, 2 items).
If the code has hardcoded logic like if (count === 1), the English version will either show «1 items» or break the counter at zero.
The same goes for cases in email and push notification templates: substituting a name into a Russian sentence works, but into an English one it gives «Hello, Ivan Ivanov!» instead of «Hi, Ivan».
The third area is layout for a different font and reading direction. English strings are on average 30% longer than Russian ones for the same meaning, and word wrapping works differently: where Russian text neatly fits into two lines, English requires three.
If the layout is built for a fixed card or banner height, the English version either truncates the text or stretches the block and breaks neighboring elements.
We start not with translation, but with an audit of the code for hardcoded strings, formats, and declension logic — and only then assemble the English version. Let's break down how this is handled at each layer.
What proper localization into English delivers
Funnel conversion drops less at the entry point
An app whose interface, error messages, and system dialogs are built for a single language loses users in the English-speaking market before they ever take a first useful action.
A person sees unfamiliar wording on the sign-up screen or in a permission request — and closes the app without ever reaching the product's value.
When strings, date, currency, and address formats are aligned with the locale, the path from install to the first target action becomes predictable: the share of users who reach it grows instead of hitting a language barrier.
Churn after the first launch decreases
The main loss happens in the first sessions: the user does not understand the prompts, cannot find the right section, and stumbles over a clumsy translation.
Localization removes this cause — the texts are written by a native speaker for the context of the screen, rather than translated line by line.
As a result, first-week retention levels out: people come back because the interface behaves the way they expect an app in their own language to behave.
Repeated interface edits are no longer needed
When strings are moved into separate resource files rather than hardcoded, adding a new language or editing wording does not require rebuilding the logic or re-approving screens.
This eliminates a whole class of tasks: marketing changes the promo text, support refines an error message — without involving developers. The interface stops being a bottleneck, and the team no longer spends cycles on repetitive tweaks.
The English-speaking market becomes manageable
Localization is not a one-time translation but an infrastructure: a unified glossary, rules for numbers and dates, and checks on string length against real screens. With it, entering a new region means enabling a language, not rewriting the product.
The effect is measurable: higher conversion in target countries, lower churn after the first launch, and no repeated interface edits with every update.
Localization approaches: manual, automated, hybrid
The choice of mode determines not only the quality of the strings, but also how the team will live with it going forward: who edits the texts, how often, and what happens when the layout is updated. Below are three working schemes with their real limits of applicability.
| Option | When it fits | Limitations |
|---|---|---|
| Manual localization | A product with legally significant texts, complex terminology, a short list of languages; a native speaker is available within the team | More time-expensive per iteration, requires a process for syncing edits with the source language |
| Machine translation | A fast entry into a new market, UI strings without legal implications, many languages with a small volume of text | Does not distinguish screen context, breaks string length and layout, requires mandatory proofreading before publication |
| Hybrid approach | The main scenario for growing products: critical content is translated manually, the rest — by machine with subsequent editing | Requires tagging strings by priority and discipline in updating translation memory |
Manual localization delivers a predictable result where an error is costly: payments, consents, legal wording.
Machine translation covers volume — it does not distinguish gender, case, and the context of a button, so strings like "Send" and "Submit request" may end up identical, and the layout will shift due to different phrase lengths.
The hybrid approach removes this limitation: strings are tagged by criticality, critical ones go to a translator, the rest go through the machine and mandatory proofreading.
Translation memory, in turn, records already approved terms — when adding a new language, the team does not translate the product from scratch, but fills in what is missing.
How we handle localization: from audit to handover
Localization is not translating strings; it is modifying the build, affecting resources, layout, and screen logic. That is why we run it as an engineering process with fixed stages: each one produces an artifact that can be verified before moving to the next step.
- String audit. We collect all text resources from the code and markup, including labels hardcoded into logic, date and number formats, error texts, and push notification content. The output is a string registry with annotations for what gets translated, what remains a constant, and what needs rework: phrase concatenation and hardcoded grammatical cases are the first things to break during localization.
- Glossary design. We build a terminology glossary and a unified style for the English version so that the same term is not translated three different ways across screens. We also account for string length headroom: English labels are on average a quarter longer than the source, and this directly affects the layout of buttons and tabs.
- Localization pipeline setup. We connect translation files to the translation management system and to the build so that updating strings does not require manual code edits. After that, new strings enter the glossary automatically, and the build picks up the current version — no discrepancies between branches.
- Layout verification. We run screens with English strings and look for where text gets truncated, wraps awkwardly, or overlaps elements. We make fixes in the markup, not by adjusting the translation to fit the source length.
- Device testing. We test scenarios on real devices: switching language on the fly, date and number formats, list sorting, search, notifications. We separately examine edge cases — long names, missing strings, behavior when switching language while the app is running.
- Handover. We deliver the glossary, the configured pipeline, and instructions on how to add new languages without rebuilding the logic. After that, the client's team expands localization independently.
This order eliminates the main cause of failures — edits to the translation when the problem is actually in the markup or screen logic.
What the client receives after app localization
Localization is not just translated strings. After the English version is released, the team is left with a set of artifacts that allow the product to keep evolving without a repeated "translation sprint" on every update.
- Localization files — structured resources by language (strings, formats for dates, numbers, currencies, units of measurement). Divided by screens and modules so that editing one phrase does not affect the others.
- Terminology glossary — an agreed-upon dictionary of product and domain concepts with translations and a "do not translate" flag. It eliminates inconsistency when the same term sounds different on different screens.
- Screen maps with string references — a map showing which key is responsible for which interface element. A new string is added in the right place, not "somewhere."
- Update procedure — the sequence of steps when adding text: who enters the string, how it gets into the localization files, what checks it goes through before release.
- Team guide — a short document for developers and content managers: how to work with keys, what to do with long phrases, how to check the layout after edits.
- Acceptance checklist — a set of checks before release: translation completeness, absence of truncated labels, correct formats and layout on real devices.
- Coverage report — the share of translated and verified strings by screen. It shows what is left, and you don't have to hunt for gaps manually.
These artifacts are handed over to the client's team along with the app. From then on, the English version is updated through the standard workflow: edits go through the glossary and the procedure, not through a one-off translation "from scratch."
Case study: how the English version stopped breaking the layout
A delivery service app came to us: the Russian version worked stably, but the English one generated a wave of complaints after launch.
On 40% of screens, text was cut off or overlapped neighboring elements — buttons ran past the edge of the card, two-line headings covered icons, and on the checkout screen the total and the field label merged into one line. Users couldn't tell what to tap and abandoned the cart at the last step.
The cause turned out to be not the translation, but the layout. The designs were built around Russian strings: fixed container widths, rigid button heights, line breaks hardcoded into the markup.
English wording is on average 30-40% longer, and where the Russian text fit, the English no longer did. On top of that came a separate problem with formats: dates, amounts, and thousands separators were rendered using a single scheme for all languages.
We started with an inventory: we went through every screen and compiled a list of places with fixed dimensions.
Then we moved the interface to self-adjusting containers — height based on content, line wrapping instead of truncation, a line-count limit only where that was a deliberate decision.
Date and number formats were moved into a separate layer that applies rules based on the selected language rather than the build region.
We also ran the layout through "long" languages — German and Finnish, where strings are even longer than English. This gave us headroom: the next localization won't require re-layout.
For verification, we set up automated screenshot tests on key screens — they catch truncation and overlap before release, not after complaints.
The result: the share of screens with cut-off text dropped from 40% to zero, and release time for updates was cut in half — fixes no longer got stuck on manually fitting every string into its container. Adding a new language now takes days, not weeks.
Duolingo
How is localization different from internationalization?
Internationalization is the engineering preparation of code for multilingual support; localization is filling an already prepared framework with a specific language.
The difference is fundamental: internationalization is done once and at the architecture level, while localization is done as many times as the number of languages you add.
If the code is not prepared for multilingual support, each new language turns into rewriting screens rather than translating strings.
At the internationalization stage, all texts are extracted from the interface into separate resource files, string concatenation from fragments and hardcoded formats are removed. Strings get keys instead of "living" directly in the screen markup.
Date, number, currency, and unit formatting is configured separately — it depends on the region, not just the language, and is applied based on the device locale. Only after that does translation become a matter of replacing a single resource file rather than editing code.
Localization begins where internationalization ends. The translator is given not paragraphs but keys with context: where the string appears, how much space it takes on the screen, what it means.
English phrases are usually longer than the source ones, so the layout is checked for overflow and truncation, not just for meaning.
Cultural adaptation is a separate task: address formats, the order of first and last names, icons and gestures that read differently in another culture.
A practical sign of properly performed internationalization is that adding a new language takes days and does not require developers to edit screens. If each language entails code changes, then the preparation was skipped, and localization follows the most expensive scenario.
That is why we always start with an audit of the code's readiness for multilingual support, and only then proceed to translating the interface.
Common technical concerns when localizing into English
Localizing into English seems simple right up until the first release: the strings are externalized, the files are translated, and yet truncated buttons and "strange" dates still pop up on the device. Below are the technical concerns that clients most often raise, and how we address them.
English text is shorter than Russian — why redo the interface layout?
It's shorter on average, but not everywhere: terms like "Save changes" or "Notification settings" are longer than the usual labels and don't fit into a fixed-width button.
That's why after translation we run a build with pseudolocalization — we substitute elongated strings and see where the text gets truncated or overlaps an icon. We make fixes in the layout, rather than "adjusting" the font by eye.
Do we need to add a separate font for Latin characters?
Usually not: platform system fonts render Latin, Cyrillic, and diacritics correctly.
Problems begin if the project uses a custom font without a full glyph set — then some characters get substituted and the layout "drifts." We check glyph coverage and, if necessary, expand the set rather than replacing the typography entirely.
Why can't we just hand the strings to a translator and paste them back?
Because some strings aren't text but logic: declensions, word order in a sentence, number and date formats. English requires a different order and different separators — "1,234.56" instead of "1 234,56," and the month before the day in dates.
We move such values into locale parameters so the format is supplied by the system rather than hardcoded in the string.
How do you handle edits from native speakers?
A native speaker sees the finished screen, not a table of strings — so the edits that come in are specific: tone, terminology, awkward phrasing. We log each edit in the translation system with the screen context, so that in the next release it isn't lost or rolled back. That way the product glossary stays consistent across releases.
Let's discuss your mobile app localization task
For the estimate to be substantive rather than "rough," four things are needed upfront: the current state of the app, the list of screens to be localized, the volume of text and layout, and the requirements for English. With this set, we come back with a work plan and timelines, not general words.
What's worth preparing for the conversation
- Platforms and current build — which versions are in production, whether there's already groundwork for multilingual support or strings are hardcoded directly in the code.
- List of screens — which sections we're translating into English: onboarding, catalog, payment, notifications, settings.
- Volume of text — the approximate number of lines and characters, including hints, errors, emails, and push notifications.
- Layout and graphics — where text is baked into images, where buttons have fixed widths and won't survive longer strings.
- Data and formats — dates, numbers, currencies, units of measurement that change when switching to English.
- Stores and rules — app description, screenshots, keywords for store listings.
- Access — repository, test builds, store accounts, if localization needs to be carried through to publication.
The conversation takes little time: you describe the task, we ask clarifying questions about screens and strings. Then comes a stage-by-stage estimate, scope of work, and rollout order.
Let's discuss your mobile app localization task — write to us about what's already done and which screens need attention.