Audit and Testing of Mobile App Localization

Testing Mobile App Localization: Typical Failures

Localization breaks not in translation but in layout: a Polish or German string is a third longer than the source, and a button with fixed width turns it into “Confirm…”.

Truncated text in the UI is the most common localization failure, and it is dangerous because meaning is lost exactly at the action: confirmation, payment, deletion.

Pseudolocalization, where strings are artificially lengthened before translation, finds such places before real languages enter the project.

Untranslated strings live where they are not visible in resource files: system permission prompts, notifications, emails, app store descriptions, error messages from server services.

Such text passes validation in the source language and surfaces only for the user, so checking language versions includes walking not only screens but everything that comes from outside the app.

Date, number, and unit formats are the second class of failures. 03/12 reads as March or December depending on locale, a comma versus a dot in decimals breaks input in fields, and plural rules for Russian (1 item, 2 items, 5 items) are not covered by simple number substitution.

Arabic and Hebrew add mirrored layout: icons, arrows, and progress bars must flip along with the text.

Mobile app localization testing follows a “screen × language × device” matrix: the narrowest and widest screen, enlarged system font, deliberately long strings, right-to-left layout.

Each language is captured with screenshots—this shows both the failure itself and that after the fix the layout did not shift in other locales.

What an Audit Before Release Delivers: Impact on Timelines and Defects

Regular localization audit moves language defects from the category of “found by the user” to “found by the check.” Version acceptance time drops from two or three days of manual proofreading in several languages to a few hours of running checks and reviewing the report—while checking not only translation but also UI layout: string truncation in buttons, line breaks, and element order in right-to-left layouts.

The main source of problems is regression of language versions. Strings change when the main branch is updated, and the language version silently loses part of the translation: plural forms for languages that have several, inflections, date and thousands separator formatting. Without checking on every build, such a defect reaches publication and surfaces in reviews.

A separate cost is release timing. A language defect is found after publication, and the “request → fix → re-acceptance” cycle in App Store shifts the release date by days, or by a week if the release is already coordinated with promotion. Checks before submission for moderation remove this class of downtime entirely.

The effect is measurable: the share of localization defects reaching the user drops to a few percent instead of tens, language version acceptance time shrinks severalfold, and repeat proofreading when adding a new language is reduced—the base set of checks carries over to it without rewriting.

Verification Methods: Manual Run-Through, Automated Tests, Hybrid Approach

Localization verification rarely comes down to a single method: the choice between manual run-through, automated tests, and hybrid is determined by the number of languages, release frequency, and how often the interface changes.

When there are dozens of screens and five or more languages, a manual pass before every release stops scaling—the reviewer only gets through one or two languages, and the rest go into release unchecked.

The opposite extreme is automated tests on a product with weekly layout edits: they have to be maintained more often than they pay off.

The hybrid provides predictable coverage: a manual run-through covers semantic translation errors, word order, and cultural nuances, while automated tests on every release check text truncation, variable substitution, and date, number, and unit formats.

The manual pass is run when adding a language, making major interface changes, and before significant releases; the automated one runs on every change. Localization regression takes minutes, and team effort goes where the machine is still powerless.

Implementation Stages: From Audit to Handover to the Team

Localization is not verified once: strings change with every release, some edits arrive after proofreading, and new languages are added one at a time.

That is why we build the implementation stages sequentially—from string inventory to a process that the client’s team then maintains on its own.

How the Sequence Is Built

1. String inventory. We collect all localization resources: string files, text in markup and code, push notifications, emails, and app store descriptions. The output is a map showing the volume for each language and the edit points.

2. Verification scheme. For each group of strings, we define exactly what is checked: length relative to the source, truncation in the UI, word order, number and date formats, plural forms, and glossary compliance.

3. Acceptance criteria. We agree on what counts as a defect and what is an acceptable deviation, and in what form the report is accepted. Without this, a dispute about an unsuccessful wording cannot be resolved.

4. Automated runs. We connect some checks to the build: empty strings, mismatched substitutions, and glossary violations stop the build before the manual stage.

5. Pilot and calibration. We run the scheme on one language and a set of screens, count the false-positive rate, and refine the rules—so the manual pass does not drag on.

6. Acceptance on the release candidate. Manual pass through key scenarios on real devices with enlarged system font—that is where truncation and line breaks most often show up.

7. Process handover. We hand over the string map, rule set, report template, and instructions for adding a new language.

Handover Package: Configurations, Schemes, Access Policies

The result of a localization audit is not a report “for memory” but a working handover package: configurations, schemes, and processes by which your team then verifies translations on its own.

Everything is put into the project repository and versioned alongside the code, so the package does not become outdated after a contractor change or an engineer leaves.

• Check configuration — rules for empty and untranslated strings, duplicate keys, substitution mismatches, and UI element overflow; runs with one command locally and on the build server.
• Screen map — a table “screen → element → string key → languages → status”: it shows which places are covered by automation and which remain for manual verification.
• Locale matrix — languages with writing direction, date and number formats, and sort order; new locales are added using the same scheme, without restructuring the process.
• Access policies — who from the team, translators, and contractors edits translation files, who only proposes edits, and how changes reach the main branch.
• String storage scheme — where resources are stored by platform, which exchange formats are supported, and how one string is reused across several screens.
• Release process — a short checklist before publishing: run the check configuration, translator confirmation of edits, and record the string state for a specific version.

The package is designed for an engineer without context: with it, verification starts on day one, not after a retelling in chat.

Case Study: Localization Audit Reduced Failures After an Update

What It Was Like Before the Audit

The client’s app shipped in eight languages, and the translation arrived as a single file a couple of days before the build.

In the German and Arabic locales, buttons and card headers were truncated, dates and amounts remained in the source language format, and part of the interface was entirely in English.

Defects were found by users: reviews on Google Play mentioned broken translation, and support received requests about confusion in payment steps.

There was no way to assess the scale—there was one build, logs were not differentiated by locale, and testing was done in one language and on one device.

What We Changed

• Pseudolocalization: strings were artificially lengthened before translation—layout truncation is visible before translators start work.
• UI automated tests by locale: screen snapshots were compared against a reference, and a difference above the threshold was marked as a defect.
• Glossary: terms, inflections, plural rules, and forms of address to the user.
• Date, number, and separator formats—through system locale facilities, not string templates.
• Device and screen size matrix, including right-to-left mode and enlarged system font.
• A set of version acceptance checks tied to the release branch.

Metrics Before and After

The first two sprints went into sorting out accumulated discrepancies; after that, the share of defects stays at the new level: they are caught at build time, not after publication. Release no longer depends on who looked at a particular locale that day.

How Does Translation Verification Differ from Acceptance Runs?

Translation verification answers the question of whether the text is written correctly; acceptance runs answer whether the app behaves correctly in that language environment.

In the first case, a linguist checks terminology against the glossary, consistency of wording across the interface, string length, and local standards for formatting dates, numbers, and units. No build is needed for this—edits go into resource files.

Acceptance runs are verification of layout and interface behavior: whether a header was truncated, whether a button broke apart from a long label, whether padding shifted.

A separate task is mirroring for right-to-left writing: text direction, element order, and gesture direction change. Pluralization and list sorting are also checked here, because language rules live in code, not in the translation file.

Data formatting errors are visible only on a live run: date and time order, thousands separators, first and last name order, and numeral inflection.

A separate class is screens where the source language is substituted instead of the translation: this manifests when switching language inside a running app, not on first launch with the device locale.

The difference in approaches sets the order of work. First, the text layer is closed out—an edit in resources does not require a rebuild and a repeat run.

Then comes an acceptance run in each target language environment: installation, first launch, purchase, switching language on the fly. A successful run in one locale does not guarantee that the same place will not break in another.

Builds and Formats: Common Questions Before Starting

Before a localization audit starts, the same set of questions comes up: how to hand over the build, where to look for strings, what order the runs go in, and what to do after edits. Below are short answers so the start does not stretch into a long chat.

Some texts come from the server—do you cover those too?

Yes, otherwise the audit covers only half the scenarios. Server responses and toggle values are not in localization files: before checking, we change the language, clear the cache, and warm up the environment again—otherwise we will see the old language and log a false defect. We separately verify the format of dates, numbers, and currencies that arrive already rendered.

What order do the runs go in?

First the base language—we catch layout regression without translation influence. Then a full language switch on the device, then pseudolocalization with lengthened strings: it shows where text is truncated or a line break breaks a button. We check right-to-left languages last—there the interface direction changes, not just the text.

Edits were made—should everything be checked again?

Repeat verification is targeted. We recheck the screens touched by the edit and search for the changed string across the whole app: one key is often used in several places. If the edit is in a shared string or template, we expand the sample to neighboring sections.

Let’s Discuss the Task: What Is Needed for an Estimate and Plan

To come back with a scope estimate and work plan rather than generalities, we need a build and an understanding of which markets are priorities for you.

Below is what we usually request in the first conversation: if something is missing, we will reconstruct part of the data ourselves from the code and test accounts.

• List of locales and market priority—it determines how many language branches we check manually and how many we cover with pseudolocalization and regular checks.
• Localization files in source form (.strings, .xml, .json, XLIFF, ARB) and glossary—they show where the translation has already diverged from the interface.
• Test build and access: accounts, staging environments, test payment scenarios, internal build distribution channel.
• Screen map with priority: registration, payment, checkout, notifications—we check these first and in more detail.
• String length limits and formatting rules for dates, numbers, units of measurement, addresses, and phone numbers.
• Requirements for text style and tone, as well as who on your side approves disputed wording.
• Release schedule: by what date the report is needed and whether there is a window for fixes before publication.
• What localization defects have occurred before and what has already been checked—so we do not duplicate work.

With this set, we map the scope of checks by locale and scenario, state the start order and the points where access is needed from your side. Describe the task in free form—we will come back with a scope estimate and work plan.