Localization Is an Engineering Problem

Localization has a reputation as a content problem: finish the product, export the strings, pay the translators, import the strings, done. Then the German build ships and the navigation wraps onto three lines, the Arabic layout reads like a mirror held up to a mistake, and the French date formats are confidently American. None of those are translation failures. Every one is an engineering decision made months earlier by someone who was not thinking about localization at all, which is exactly the problem.

We have shipped multilingual builds for clients including Møller, whose market map spans a dozen locales, and the lesson is consistent: localization quality is determined by architecture long before a translator sees a word.

Strings are structured data, not sentences

The root failure is treating UI text as strings to be swapped when it is actually structured data with grammar attached. English concatenation habits produce untranslatable fragments: "You have " + count + " items" hard-codes English word order and English pluralization, and many languages have more than two plural forms. Russian has three in common use; Arabic grammar distinguishes six categories.

The fix has existed for years: ICU MessageFormat, where the message owns its grammar.

{count, plural,
  =0 {No saved designs}
  one {# saved design}
  other {# saved designs}
}

Every string in the codebase goes through the message system from day one, with no exceptions for "text that will never change." That text always changes, usually in week three of the translation pass, at maximum cost.

Layout must assume it is wrong

English is a compact language. German runs roughly a third longer on average, and short UI labels can double. Finnish and Hungarian do their own expanding, while Japanese often contracts. Any layout that only works at English lengths is a defect that has not localized yet.

Our rules of thumb: no fixed widths on text containers, truncation as an explicit design decision with a tooltip or wrap strategy, buttons and navigation tested at 140 percent length, and line height that survives scripts with taller glyphs than Latin. For right-to-left support, we use CSS logical properties, margin-inline-start instead of margin-left, from the first component. Retrofitting RTL into a codebase full of physical directions is one of the most tedious jobs in frontend; writing it correctly from the start is nearly free.

Pseudo-localization in CI, or it did not happen

You cannot wait for real translations to find these bugs, and you do not have to. Pseudo-localization runs the English build through a transformer that lengthens every string, wraps it in markers, and swaps in accented characters: "Àççôûñţ šéţţîñĝš one two three." Broken layouts, clipped text, and hard-coded strings light up instantly, because a hard-coded string is the only text on screen not wearing the costume.

We run a pseudo-locale build in CI with visual regression screenshots on key pages. Hard-coded string sneaks in, the diff catches it that day rather than in the Norwegian QA pass next quarter.

Formatting is not sprinkled, it is centralized

Dates, numbers, currency, and lists all format differently per locale, and the platform already knows how: the Intl APIs handle it natively. The engineering discipline is centralization. One formatting module, locale-aware, used everywhere, so "11/13/2024" versus "13.11.2024" is a configuration fact rather than a bug report. Currency deserves special paranoia: position, spacing, and decimal conventions vary, and getting money formatting wrong reads as carelessness in exactly the place users are least forgiving.

The one-sentence policy

If your roadmap includes even a possibility of a second language, the policy is: build localized from the first commit and let English be merely the first locale. The overhead is a rounding error on a greenfield build and a rewrite on a mature one. Translation is the cheap part. It is the code around the words that decides whether your brand travels.