Software Internationalization Services for Multilingual Products

Why Most Software Fails Internationally (the Retrofit Trap)

Most software fails abroad for one reason: it was designed for one language and translated later. The words are only the visible layer. Underneath sit hardcoded strings, layouts sized for short English labels, date logic that assumes one calendar convention, and a database that stores text without asking what script it holds.

That costs you sales. CSA Research's "Can't Read, Won't Buy" study of 8,709 consumers across 29 countries found that 76% prefer to buy products with information in their own language, and 40% will never buy from websites in other languages. Fewer than 20% of the world's population speaks English, yet almost half of all websites are written in it (Statista, 2026). An English-only product competes for a minority of its market.

Retrofitting is the expensive fix. Adding languages to a monolingual codebase means touching every layer at once (UI strings, validation, emails, PDFs, database fields, search) while the product keeps shipping. Teams report two to five times more engineering effort for a retrofit than for building the same support in from the start (XTM, 2026). Most find out mid-project that they budgeted for translation and bought re-engineering.

We see the same failures so often that we cataloged them: why software fails internationally lists the seven mistakes we find most, and what each one costs to undo.

i18n Architecture: What to Build in from Day One

A multilingual-first architecture comes down to a short list of concrete decisions. Made at the start, each one costs little. Retrofitted, each one costs a lot. Here is what goes into every build we ship:

1. Unicode everywhere. Unicode assigns a code point to every character in every writing system, and UTF-8 is its dominant encoding. Every database column, API, file export and email template we build is UTF-8 end to end, because one legacy component with a different encoding is enough to corrupt names and addresses. That garbage text has a name, "mojibake", and we dissect it in Unicode in business applications.
2. Externalized strings. No user-visible text lives in code. Every label, error and email sits in resource files with stable keys, ready for translators. Sentences are never stitched together from fragments, because word order changes per language.
3. ICU message formatting. ICU (International Components for Unicode) is the open-source library that handles plurals, gender, lists and formatted values per language. English has two plural forms, Arabic has six, and Polish rules change with the number itself. String templates can't cope with that. ICU can.
4. CLDR locale data. CLDR (the Common Locale Data Repository, maintained by the Unicode Consortium) supplies the facts of each locale, a locale being a language-plus-region pair such as fr-BE: date patterns, number separators, currency symbols, sort orders. We use it instead of hand-maintained format tables.
5. A translatable data model. UI strings are half the problem. Product names, categories, document templates and notifications live in the database, so the schema stores them per language from day one, usually behind a multilingual CMS or localized content fields.
6. hreflang and locale routing. hreflang is the HTML annotation that tells search engines which language version of a page to show each user. We generate it from the locale configuration, never by hand.
7. Pseudo-localization in CI. Pseudo-localization swaps text for accented, lengthened dummy strings such as "[!!! Àççôûñt Šéttîñgš !!!]" to expose hardcoded text and breaking layouts before a single word is translated.

The rest of our practices are collected in building apps for global users. In your build, the i18n acceptance criteria that enforce them go into the fixed scope.

RTL, CJK, and the Scripts That Break Naive UIs

Two script families expose weak internationalization faster than anything else. Catch them in testing and your users never see the breakage.

Right-to-left (RTL) scripts, Arabic and Hebrew, flip the reading direction of the entire interface. Proper RTL support means mirrored layouts (navigation, icons, progress flows), logical CSS properties instead of left/right values, and correct bidirectional text, where an Arabic sentence contains a Latin product code or a phone number reading the other way. A naive UI turns RTL text into visual scramble, and users notice within seconds.

CJK scripts (Chinese, Japanese, Korean) break different assumptions. No spaces between words, so line breaking has to understand the script. Denser characters, so type sizes and line heights tuned for Latin text become unreadable. Search, sorting and input methods behave differently too.

Then there's text expansion. German labels run roughly 30% longer than English, and even everyday words outgrow fixed-width buttons. Layouts have to be tested against real scripts, not translated last, so every multilingual build we ship is tested with pseudo-localization plus at least one RTL and one CJK locale.

Translation Pipelines: Connecting Your App to Professional Translation Workflows

Translation pipelines are our home turf. A translation pipeline is the automated route your content takes from the codebase to translators and back. It keeps multilingual software current, release after release, instead of translated once and left to go stale.

A production pipeline has five stages:

1. Extraction. New and changed strings are detected automatically on every release. Nobody emails spreadsheets.
2. TMS handoff. A translation management system (TMS) routes content to translators and tracks progress. It applies translation memory (approved translations, reused instead of paid for twice) and terminology glossaries, so your product vocabulary stays consistent across releases and languages.
3. Translation. Human translators, machine translation, or machine translation post-editing (MTPE: machine output reviewed and corrected by a professional), chosen per content type. Legal text and UI strings earn human care. Bulk catalog descriptions often justify MTPE.
4. Review in context. Translators see strings where they appear, not in a spreadsheet column. Most translation defects are context defects.
5. Merge and deploy. Approved translations pass the same review gates as code. With continuous localization the loop runs on every release, so no language ever waits for a "translation phase".

We ran workflows like these across dozens of language pairs for over 20 years, as the translation provider, coordinating hundreds of professional linguists against fixed deadlines. Tool choices and the full architecture are in our guide to translation pipelines.