How to review machine-translated app strings with a native speaker

How do you review machine-translated app strings?

Give a native speaker the strings, the source text, and the screen where each string appears. The reviewer checks each string for meaning, tone, terminology, placeholders, plurals, and length, then corrects the AI output. The reviewer fixes errors and does not retranslate from scratch, so a review should take less time than a full translation.

1. The translation says what the source says on that screen.
2. The level of formality fits the product and the market.
3. Product and feature names match the glossary and stay consistent.
4. Variables such as a customer name or a count, called placeholders, stay intact.
5. The string has every plural form the target language needs, because Polish, for example, uses different noun forms for one item, a few items, and many items.
6. The text fits the button, label, or field where it appears, because translated text is often longer than the source.

My view is that meaning and context checks come before polish, because a polished wrong meaning is the hardest error to find. For the wider workflow around strings, see our guide to software localization. 

Why do AI models need context to translate app strings correctly?

Short strings carry almost no context, so an AI model has to guess the meaning from a word or two. The word book can be a noun or a verb, and for that reason Xcode now passes context about each string to the translation agents in Apple's WWDC 2026 session.

In Apple's demo, the agent adds plural variations and picks the correct regional French term for landmarks (Apple, 2026). Context improves the first draft. As far as I understand, it does not tell the model whether a term fits your brand or a regional norm, which is where a native speaker still adds value.

Does machine-translated app text need a native review before release?

It depends on the string, because the cost of an error varies by where the string appears. A wrong label on a settings screen is a small embarrassment, while a wrong error message, payment prompt, privacy notice, or health instruction can cost a customer or create legal exposure.

In my opinion, those higher-risk strings should be reviewed by a native speaker before release, and privacy, legal, and health text deserves a human translator or a reviewer with subject knowledge. For legal text, see our legal translation services.

Tomedes is certified to ISO 18587:2017, the international standard for human post-editing of machine translation output. Legal and medical work shows among the lowest AI-assisted shares in our 2026 orders, between 5.6% and 7.3% for legal categories and between 2.4% and 6.4% for medical categories.

How much app string work at Tomedes involves reviewing machine translation?

In 2026, 15.5% of our UI string and software orders included an MTPE line, which means a linguist reviewing and correcting machine translation output. Most of these orders do not include one.

That figure is lower than the AI-assisted shares in our earlier order analysis, because this one counts only MTPE lines and a different set of UI and software categories. The difference between AI post-editing and MTPE is covered in our guide to AIPE vs MTPE.

Across all global orders, the share with a review of machine or AI output peaked at 27.0% in March and was 13.8% in October. My read is that one large client drives most of that volume, so I would not call it a market trend.

What changes when an app ships in three or more languages?

Each target language needs its own native reviewer, so review cost and coordination grow with every language added. About three in four of our UI string and software orders in 2026 asked for three or more target languages, so the multi-language case is the usual one.

The count comes from the distinct target languages named in each order's product lines, so it can miss languages batched under one project line and may undercount. In October 2026, one lead asked for a native review of machine-translated app strings in 16 languages.

I think a review that follows string risk is the practical way to keep that scale affordable, because a full review in 16 languages multiplies the work by 16.

How should you scope a native review of AI-translated strings?

Scope the review by string risk, so the reviewer's effort goes where an error costs the most. Spot-check low-risk labels in context, review error messages, onboarding text, and payment text in full, and send privacy, legal, and health text to a human translator or a reviewer with subject knowledge.

Suggested review level by string type

My preference is to run automated checks for placeholders and length before the reviewer starts, so the reviewer's time goes to meaning and tone. If a spot check finds repeated errors in one group of strings, widen the review for that group.

What should you send with the strings for a review?

Send the source strings, the AI-translated strings, and the context a reviewer needs to judge them. A native reviewer can fix meaning and tone only when they can see where a string appears and how long it can be, so context matters as much as the text.

1. Screenshots, or a description of the screen, for each group of strings.
2. A glossary of product and feature terms.
3. Character limits for buttons, labels, and fields.
4. The target market, and whether the product addresses customers formally or informally.
5. The file in the format your build uses, for example iOS string catalogs, Android string files, or JSON.

I could be wrong on this, but I expect agent-based tools like the one in Xcode to produce more AI-translated strings with less time to check them. A review that follows string risk means the people checking spend their time where an error would hurt. 

Already have machine-translated app strings? Talk to Tomedes about AI translation with a native review, or see our localization services.

FAQs

Q: How do you review mobile phone app localizations?
A: Check each string in context on the screen where it appears, comparing the translation with the source for meaning, tone, terminology, placeholders, plurals, and length. A native speaker of the target language should do the review, because fluent-looking errors are hard to spot without that fluency.

Q: Why do translations break layouts in software?
A: Translated text is often longer than the source, and a fixed-width button or label may not hold it. Word length and line breaking also differ between languages. Reviewers and localization testing catch these problems before release, and flexible layouts with character limits prevent many of them.

Q: Is AI localization good enough without human translation?
A: It depends on the string, because AI localization works well for low-risk labels and poorly where an error is costly. Error messages, payment text, privacy notices, legal text, and health instructions should be reviewed by a native speaker or translated by a human before release.

Q: What service should you use to translate UI strings?
A: Choose by string volume, number of languages, and risk. Machine translation with a native review suits large, low-risk batches, human translation suits high-risk text, and a translation company can combine the two. Whatever you use, ask who reviews the final strings in each language and whether they see them in context.