Poor context is one of the leading causes of localization quality issues. A translator who sees the word “Save” in a spreadsheet cannot tell whether it is a button or a discount.
For developers, product managers, and localization managers, the cost shows up late. Strings glued together in code, plurals that only work in English, and buttons that overflow in German or Malay all return as bug tickets after the translation budget is already spent.
The fix starts before any file reaches a translator. Clean internationalization even improves machine translation, because externalized strings with named placeholders give the engine complete sentences with context. This software localization checklist covers code, string writing, context, cleaning the string set, testing, and a final one-page list.
Internationalization vs Localization: What to Fix in Code Before Translation
Software internationalization (i18n) is engineering work: making the code able to support any language, script, and format. Localization (l10n) adapts the content for a specific market. Translators cannot fix internationalization problems, so they have to be solved first, as part of broader software localization best practices.
Externalize Hardcoded Strings for Localization
A basic readiness rule is to externalize all user-facing strings to resource files. Text written directly into components never reaches the translation file and ships in English. Use translation keys from the very beginning, even if you only ship in one language at first.
Translation Key Naming Best Practices
In many tools, the key is the only label a translator or reviewer sees. Keep translation keys descriptive and scoped to their feature context: checkout.orderSummary.totalItems tells everyone where the string lives, while a generic key such as title collides with dozens of others. Never reuse one key for two meanings just because the English text matches.
Rewrite Strings So Translators Can Translate Them
Avoid String Concatenation in Localization
Code such as “Your order number is: ” + orderNumber looks harmless, but the translator receives only a fragment. Rewrite it as one complete message, “Your order number is: {orderNumber}”, so the translator can place the variable wherever the target grammar needs it. The rule is blunt: concatenation locks the word order to English and makes correct translation impossible.
ICU Plural Rules in UI Strings
English has two forms: 1 file, 2 files. Many languages have more, and some have none. Platform mechanisms such as iOS .stringsdict and Android plural resources exist because plural and gender rules vary far more than English suggests. In web apps, ICU MessageFormat does the same job: {count, plural, one {# file} other {# files}}.
If the source string isn’t structured for ICU plurals, translators have no way to provide the forms their language demands. Also, never join placeholders to units such as {duration}day or {size}MB; use a unit formatter so each locale controls spacing, order, and abbreviation.
Give Every String the Context Translators Need
Translator Context for UI Strings
Translator context for UI strings tells the translator where text appears, what it does, and what each placeholder holds. For ambiguous keys, attach a screenshot or Figma link to the key along with a short description. Descriptions can be brief, like the FormatJS example “Label before a relative time”. Flutter teams get this built in: the ARB format has context, description, and screenshot attributes for each resource, so the metadata travels with the file.
Character Limits for UI Translation
Buttons, table cells, and mobile notifications have hard ceilings. Define those limits before translation, because without character limits, translators produce correct copy that breaks your layout. Store each limit in the key metadata so translators see it in their tool.
Pre-Translation Checklist for UI Strings: Clean the String Set Before You Send It
Remove Non-Translatable Strings and Duplicate Keys
A practical pre-translation checklist includes non-translatable strings excluded or marked, no hardcoded strings left in UI components for the release, duplicate keys resolved, and only new or changed strings flagged. Brand names, API values, log messages, and CSS class names usually belong in the non-translatable group.
Glossary for Software Localization
A glossary for software localization keeps product terms consistent across translators and releases. Each entry should hold the meaning, context and an example sentence, approved translations per locale, and forbidden translations. The same guidance adds a caution: the glossary guides meaning, but grammar still adapts. Do not use it to force one translation into every context.
Test Before Real Translations Exist
Pseudo-Localization and Layout Tests
Pseudo-localization swaps source text for accented. It exposes hardcoded strings, which appear unaltered and are therefore immediately visible, along with truncation and layout overflow. Test every layout for 30 percent text expansion.
Automated Checks Before Accepting Translations
When translations come back, automated QA should validate placeholder integrity, length limits, and forbidden terms before files merge into the build. Pair these checks with translation quality assurance tools and human linguistic review.
The Final Pre-Translation Checklist
Run this one-page software localization checklist before every translation handoff:
- All user-facing strings extracted to resource files
- Translation keys named by feature, screen, and element
- Full sentences with named placeholders, no concatenation
- Plurals written in ICU or platform plural formats
- Descriptions and screenshots attached to ambiguous keys
- Character limits defined for constrained UI elements
- Glossary terms approved and shared with translators
- String set cleaned: non-translatables marked, duplicates resolved, only new or changed strings sent
- Pseudo-localization test passed with 30 percent text expansion
For wider preparation such as scope, file formats, and vendor briefing, see our guide on what to check before you localize your software.
Localization-ready strings save revision rounds at the QA stage: fewer bug tickets, fewer retranslations, and releases that ship on schedule. Working through a software localization checklist before handoff is the cheapest quality step in the whole process. Since 1998, SpeeQual has supported UI string localization for software teams, from string review and glossary building to translation and linguistic QA. Explore our software localization services, or get in touch to prepare your next release.
