UI strings & i18n review
The shortest strings cause the biggest bugs. We translate and review UI strings with placeholder safety, truncation checks and pseudo-localization, so every language builds and reads correctly.
One word, ten ways to break
A UI string is the hardest kind of text to translate well, for reasons that have nothing to do with vocabulary. It is short, so there is no surrounding sentence to disambiguate it. It lives inside a layout, so it has a maximum length nobody wrote down. And it often carries code — placeholders, variables, plural rules — that must survive translation byte-for-byte.
That combination produces a specific family of bugs: the German label that overflows its button, the {username} placeholder that a translator “translated”, the plural string that reads correctly for 2 items and wrong for 5, the “Back” button translated as a body part. Each one is small. Together they make a product feel broken in every market at once.
What we check, string by string
Our software practice group translates and reviews UI strings against a checklist built from these failure modes:
- Placeholder and variable safety — {count}, %s, %(name)s and ICU syntax locked as untouchable tokens, then machine-verified against the source in every target string
- Plural rules per language — every required plural form translated, ICU syntax validated, so counts render correctly from zero upward
- Length and truncation — German and French run roughly 30% longer than English; strings are checked against character limits where you provide them, and flagged where you do not
- Context verification — translators work from screenshots, string descriptions or a staging build, and ambiguous strings come back as questions rather than guesses
- Terminology consistency — one term base per language, so the label on the button matches the docs, the tooltips and the marketing site
Every language is handled by a native-speaking reviewer with software experience. Automated checks catch what machines catch well; a human decides what ships.
Pseudo-localization: find the breakage before you pay for it
Pseudo-localization is the cheapest i18n investment you can make. Before any real translation starts, your English strings are replaced with artificially expanded, accented text — “Settings” becomes something like [Šéttîñgš one two] — and the app is run as if that were a real locale.
The build immediately shows you three things: layouts that break under 30% text expansion, strings hardcoded in the source instead of externalized in resource files, and characters your fonts or encoding mishandle. Fixing these before translation means you fix them once — not once per language after the translations come back.
Auditing what you already shipped
If your product is already localized, we review rather than retranslate. A native reviewer walks your UI in context — real screens, not spreadsheets — and returns a prioritized list: genuine mistranslations first, truncations and broken variables next, tone and consistency issues last. You fix what matters and skip a full retranslation you probably do not need.
Like every Link Translation project, it starts with a fixed quote within 24 hours. Send us your string files and, if you have them, screenshots or a test build — the more context, the fewer guesses anyone has to make.
Frequently asked questions
What is pseudo-localization?
A test technique: your English strings are replaced with artificially lengthened, accented text (like [Šéttîñgš!!!]) before real translation starts. Running the app this way reveals which layouts break under longer text, which strings are hardcoded, and which characters render wrong — while the fixes are still cheap.
Can you review translations we already have?
Yes — this is one of the most common ways teams start with us. A native-language reviewer audits your existing UI translations in context, flags mistranslations, truncations, broken placeholders and terminology drift, and returns a prioritized fix list instead of a vague quality score.
How do you keep variables and placeholders safe?
Placeholders like {count}, %s or ICU plural syntax are locked as untouchable tokens in the translation environment, so they cannot be deleted or reordered by accident. Automated checks then verify every placeholder in every target string against the source before delivery.
Why do plurals need special handling?
English has two plural forms; Russian has three in common use, Arabic has six, Japanese has one. A string like "{count} files" needs a plural rule per language, not one translated sentence. We translate every required plural form and verify the ICU syntax so your library renders each correctly.