We tested everything. The strings fit. The layout looked clean. QA signed off.
Then we shipped in 7 languages, and the problems started showing up in places no one had thought to look.
Some internationalization failures are obvious in development. The ones that really hurt you are the ones that pass every internal review and break in production. Here are the patterns I’ve seen over and over.
QA happened in the source language, not the target ones.
Most teams test with placeholder translations or short strings. Real translations arrive late and get a quick visual pass at best. So teams ship confidently, then discover that the German marketing copy in the hero section is 40% longer than the English version, or that the French legal disclaimer wraps in a way that obscures an action button. These aren’t development bugs. They’re process gaps.
The translator did their job. The string structure didn’t.
On one product, we had a string that read “This file was shared with you and 12 others.” Simple enough in English. When the string was sent for translation, it was split in 4 — “This file was shared with,” “you,” “and,” and “others” — so the software could assemble it dynamically at runtime. Those pieces arrived with no sentence context. In German, the word “you” changes form depending on its grammatical role in the sentence. “Shared with you” needs “dir.” Without the full sentence, the translator had no way to know that. They made a choice. It was the wrong one. The result was a professionally translated product where certain strings were grammatically correct in isolation and awkward in context. Nobody caught it in QA because nobody on the review team was a native speaker.
AI translation is cheaper than human translation, and riskier than most teams realize.
Teams will use AI translation. The cost difference is real. But I have seen perfectly innocuous strings come back as vulgar language from an AI Thai translation. The cost savings disappear fast when you’re doing emergency retranslation after launch, or managing the brand damage. If you use AI translation, pair it with a fluent human reviewer before anything ships. This step should not be optional.
The edge cases only exist in real locales.
Your input validation probably works fine until you try it with a Japanese name, a German street address, or a Brazilian postal code. Character limits, regex patterns, field labels that assume a “first name / last name” model — these all feel universal until they meet actual users. Automated testing won’t surface them because your test data was written by someone working in the source language.
Legal and formatting requirements sneak up on you.
These are easy to hard-code accidentally when you’re designing for one market. Consider dates:
- March 29, 2026 in English
- 29. März 2026 in German
- 2026년 3월 29일 in Korean
Numbers:
- 123,456.789 in English
- 123 456.789 in French
- 123.456,789 in German
Currency:
- $123.45 in English
- 123.45 € in French
- € 123,45 in Italian
None of these are wrong, they’re just different. If your product hard-codes one pattern, some of your users are reading something that looks off at best and incorrect at worst.
The UI was designed for one reading pattern.
English and most Western European languages read left to right, top to bottom, with visual weight on the left side. If your design buries important information on the right, or uses directional metaphors like “swipe right to accept,” those choices don’t hold up in RTL languages or in markets where scanning patterns differ. No one flags this in internal review because everyone in the room reads the same way.
The common thread across all of these: they passed review because review was done by people who share the same assumptions the design was built on.
The fix isn’t just better tooling. It’s inviting people who don’t share those assumptions into the review process earlier. A native speaker doing a 20-minute walkthrough will catch things no automated tool will.
What internationalization mistakes have you seen that made it all the way to production?