5 Common Mistakes Teams Make When Localizing Their App
After watching enough products expand into new languages, the same handful of mistakes show up again and again — and almost none of them are actually about translation quality. They're process gaps that are cheap to fix once you know to look for them.
1. Hard-coding strings instead of using keys
Text embedded directly in components has to be found and extracted by hand the day you decide to support a second language — often turning a translation task into an engineering project. Every user-facing string should be behind a key from day one, even if you only support one language today.
2. Translating without context
A translator handed a spreadsheet of bare strings has no way to know that "Close" refers to a modal dialog in one row and a stock market status in another. Attach context — screen name, a screenshot, or a short note — to every string, especially short ones that are ambiguous on their own.
3. No review step before publishing
Publishing a translation the moment it's submitted, with no second person checking it, means the first time you find out a translation is wrong is when a user reports it. A simple two-status model — needs review, then approved — catches most mistakes before they're visible to anyone.
4. Ignoring text expansion and contraction
German and Finnish translations routinely run 30–40% longer than their English source; some Asian languages run shorter. A button sized exactly to fit English text will visibly break the moment it's translated. Design UI with room for text length to vary, and actually look at the translated UI before shipping — not just the translated strings in isolation.
5. Treating localization as a one-time project
Localization isn't a task you finish once — it's an ongoing process that has to keep pace with every new feature you ship. Teams that treat their first translation pass as "done" end up with new features shipping in English only, and existing translations slowly drifting out of sync with the product. Wiring translation into your regular release process (see continuous localization) is what keeps it from becoming a recurring fire drill.
The common thread
None of these are language problems — they're workflow problems. A team that extracts strings properly, gives translators context, requires review, designs for text expansion, and treats localization as continuous will produce better translations with less talent than a team skipping all five, no matter how good their translators are.