Key takeaways
- Never build sentences by concatenating fragments; ICU says a message has to be written and translated as a single unit.
- Unicode CLDR defines six plural categories (zero, one, two, few, many and other), and many languages use more than two.
- IBM guidance cited by the W3C expects English strings of up to 10 characters to expand by 200–300% in translation.
- Every string sent for translation should carry context: where it appears, what any placeholder means and its maximum length.
- Pseudo-localisation exposes hard-coded text, concatenation and truncation before any translation is paid for.
This article is for developers, product owners and localisation managers working on desktop software, web applications and SaaS products. It sets out the practical rules that keep UI strings translatable, and explains what translators need from you to get them right first time.
Translation quality in software depends as much on how strings are written and delivered as on the translator's skill. A perfect translation of a badly built string can still produce a broken interface.
What is a UI string, and why is it harder to translate than a document?
A UI string is a single piece of user-facing text, such as a button label, menu item, tooltip or error message, stored with a key (an identifier) in a resource file. Strings are harder to translate than documents because they are short, appear out of order and often lack any visible context.
A translator may see "Open" or "Clear" alone in a list of thousands of entries. Without knowing whether it is a verb or an adjective, a button or a status, the translator has to guess. Many languages need different words for each case.
What should developers do before strings go to translation?
Developers should make the code ready for any language before translation starts. This preparation is called internationalisation, and it is far cheaper than fixing each language later. Our article on translation vs localisation vs internationalisation explains the difference between the terms.
Externalise every user-facing string
All user-facing text should live in resource files, not in code. Android's guidance puts it plainly: "As you build your apps, don't hardcode any strings." (Android Developers). The same principle applies on every platform.
Never concatenate sentences
Word order changes between languages, so sentences built from fragments cannot be translated correctly. The ICU project, which maintains widely used internationalisation libraries, states that "For this to work in many languages, a message has to be written and translated as a single unit" (ICU User Guide: Formatting Messages). Use one complete string with placeholders instead.
Use named placeholders
Write "{userName} shared {fileName}" rather than "%s shared %s". Named placeholders tell translators what each variable contains and let them move it within the sentence.
Handle plurals properly
Many languages have more than two plural forms. The Unicode CLDR project defines the categories "zero", "one", "two", "few", "many" and "other" (Unicode CLDR: Plural Rules). Use a plural-aware format, such as ICU MessageFormat or the platform's plural resources, instead of an "if count equals one" test.
Do not reuse one string in different contexts
Reusing a single "Save" key for a button, a menu heading and a status message saves a few words but breaks languages that need different forms. Give each context its own key.
Format dates, numbers and currency by locale
Use the locale data built into your platform or library rather than hand-built formats. Most systems draw on the Unicode CLDR, which its maintainers say is used by Apple, Google and Microsoft.
How much extra space do translated strings need?
Translated strings usually need more space than English, and short strings grow the most. The W3C publishes IBM's guidance on expected expansion:
| Length of English source text | Average expansion in translation |
|---|---|
| Up to 10 characters | 200–300% |
| 11–20 characters | 180–200% |
| 21–30 characters | 160–180% |
| 31–50 characters | 140–160% |
| 51–70 characters | 151–170% |
| Over 70 characters | 130% |
Source: W3C: Text size in translation. Design buttons and labels to grow, and give translators a hard character limit only where space is truly fixed.
What context do translators need for each string?
Translators need enough context to know what each string does, where it appears and how much space it has. A good string export includes:
- a description or comment for anything ambiguous, such as "Button that empties the shopping basket";
- a screenshot or link to the screen where the string appears;
- the maximum length, in characters, where the layout is fixed;
- placeholder explanations, such as "{count} = number of unread messages";
- the user's situation, for example whether an error appears before or after payment;
- a glossary of product terms and how they are translated, as covered in our guide to glossaries and style guides.
Which file formats are used for software localisation?
Software localisation uses a small number of standard resource formats, and professional translation tools can open most of them directly. Sending native files avoids copy-and-paste errors.
| Platform or framework | Common resource format |
|---|---|
| Android | strings.xml resource files |
| Apple platforms | String Catalogs (.xcstrings), older .strings files |
| .NET | .resx resource files |
| Open-source and Linux projects | gettext .po files |
| Web applications | JSON or YAML key-value files |
| Exchange between tools | XLIFF |
Whatever the format, preserve keys, placeholders and markup exactly. Translation tools protect them, which is one reason to avoid sending strings in word-processing documents. For more on preparing files, see how to prepare files for translation.
How should localised software be tested?
Localised software should be tested twice: once with pseudo-localisation before translation, and once in each real language before release. Each test finds different problems.
Pseudo-localisation swaps the source text for longer, accented placeholder text. Android's pseudolocales, for example, reveal "UI layout issues caused by text expansion" and show concatenated strings as "one message split across two or more brackets" (Android Developers). Real-language testing then checks meaning, tone and fit, as described in our article on linguistic quality assurance (LQA).
How do you keep localisation in step with frequent releases?
Teams that release often should treat localisation as part of each sprint rather than a project at the end. In practice that means:
- setting a string freeze date before each release;
- sending only new and changed strings, with context;
- keeping a shared translation memory so that unchanged text is never paid for twice (see translation memory explained);
- building translated files automatically and running a quick visual check in each language.
Common mistakes in UI string localisation
These mistakes cause most of the rework we see in software projects:
- Text embedded in images or icons, which cannot be translated without new artwork.
- Changing a source string but keeping its old key, so the old translation stays live.
- Translating strings in a spreadsheet with no screenshots or descriptions.
- Assuming left-to-right layout, which breaks Arabic and Hebrew interfaces.
- Sorting lists alphabetically using English rules in every language.
Game interfaces follow the same rules; our guide to video game localisation covers the wider process, and mobile specifics are in our mobile app localisation guide.
How TranslationWorks can help
TranslationWorks is a UK-based translation agency that translates software interfaces, help content and documentation into 150+ languages, using native-speaking linguists. Our IT and gaming translation team translates interface strings, error messages and in-app help, and our translation services cover the user guides and release notes that ship alongside your product.
We are ISO 17100 certified, ISO 9001 and ISO 27001 registered and Cyber Essentials certified, which matters when you share source files and unreleased features. Send us a sample export and your target languages, and we will reply with a free software localisation quote within 24 hours.
