Why string concatenation breaks your localization – and what to do instead
If you are planning to have your software localized, string concatenation is a habit worth breaking.
String concatenation is the process of joining short strings to form a new string: e.g. sentence_start + variable + sentence_end.
Appending strings together like that almost always results in localization bugs, because word order, prefixes, suffixes, and grammar rules vary significantly across languages.
If you are planning on having your software localized, this is a practice you should avoid.
Issues are typically caused by:
Varying Word Order: A common pitfall is the use of modifiers. In English, a color usually precedes the noun (e.g., "red pencil"), but in French, for instance, the modifier often follows it ("crayon rouge"). Concatenation forces a fixed English structure that is incorrect in many other languages.
Complex Grammar Rules: English has simple rules for variables, but other languages have dozens of conjugations, gender agreements, and plural forms that change based on the content of a variable. In Dutch, for instance, the adjective may have a different inflection, depending on the noun: “groot” or “grote”. Concatenation makes it impossible for translators to account for these dependencies without creating dozens of unique use cases for every single language.
"Word Puzzles" for Translators: Splitting a sentence into several keys creates "word puzzles" that are difficult or impossible to translate. Translators often work on context-free files and may only see a fragment of a sentence, leaving them to guess what the missing parts are (like the word "at" as a string – will this be followed by a time? a place?).
The Solution: Parametrized Strings
Instead of concatenation, developers should use complete sentences with placeholders (also known as parametrized strings) and punctuation within the string.
This allows for translator control: using a placeholder like %(count)s within a full sentence allows translators to change the word order freely and insert necessary prefixes or suffixes required by their language's grammar.
When using multiple parameters, named-string interpolation is recommended (e.g., {day}) rather than positional interpolation (e.g., %s). Positional interpolation prevents translators from swapping the order of variables in sentences with more than one variable, which is often required in translations (e.g., swapping month and day in a date).
Also include punctuation in your sentences. Tacking on punctuation like colons or spaces after a string is considered a form of bad concatenation. Usage rules for punctuation differ; for example, French requires spaces around colons, whereas English does not. Therefore, all punctuation should be part of the translatable resource string.
Conclusion
String concatenation might feel like a minor shortcut during development, but it creates disproportionate problems the moment your software moves into localization. What looks like a simple joined string in English can become an untranslatable puzzle in Dutch, a grammatically broken sentence in German, or a nonsensical fragment in Japanese.
The solution is straightforward: treat every user-facing string as a complete, self-contained sentence with named placeholders for any variable content, and keep punctuation inside the string where it belongs. These are small habits that cost almost nothing to adopt early — and can save significant time, budget, and frustration when your localization project begins.
Thinking about localizing your software for the Dutch-speaking market?
I've put together a free localization preparation checklist for software teams.
It will be available soon, but readers of my blog can have it earlier, since I appreciate you being here!
Get in touch if you'd like a free copy.