i18n Breaks Outside the Translations

"We'll just translate the strings at the end." Projects that start with that assumption tend to hit a wall right before launch: English labels overflowing buttons, tables collapsing when German text wraps, forms that reject perfectly valid names. The cause is rarely translation quality. It's that nobody decided the scope of internationalization during requirements. This article gives you a checklist for finding the places that break outside the translations, before any code is written.

Why "translate later" breaks things

Screens and logic are built around the language of the people who design them. Design in Japanese and you naturally assume short labels, a fixed word order, and no singular/plural distinction. Pour another language in later and those assumptions fail all at once. Translators can translate words, but they can't widen a button or fix how variables are inserted into a sentence. That's why this belongs in requirements, not in the translation step.

Five things to decide during requirements

1. Text expansion

Going from Japanese to English often makes text two to three times longer, and German or French can be longer still. Even from English, translations commonly grow 30% or more. "Save" may fit, but "Save as draft" wraps onto two lines.

• Decide the longest supported language and a target expansion ratio
• List fixed-width components: buttons, tabs, table headers
• Decide what happens when text doesn't fit (wrap, or truncate and show the full text elsewhere)

2. Word order and variable placement

Building sentences by concatenating fragments breaks in languages with different word order.

// Bad: word order is hard-coded
const msg = user + " reported " + count + " bugs";

// Better: one translation key per sentence, named variables
t("reported", { user, count });
// en: "{user} reported {count} bugs"
// ja: "{user}さんが{count}件のバグを報告しました"

Write it down as a requirement: never concatenate sentence fragments; every sentence gets its own key.

3. Plurals

Japanese uses the same form for one item or three, while English switches between "1 bug" and "3 bugs". Some languages have three or more plural forms. Requiring a plural-aware mechanism such as Intl.PluralRules or ICU message format prevents output like "1 bugs".

4. Names, addresses, dates, and numbers

• Names: requiring separate first and last name fields excludes people with a single name or very long names
• Addresses: restricting postal codes to one country's format blocks international users
• Dates and numbers: "10/07/2026" and "1,000.5" are written differently by region. Format for display with Intl.DateTimeFormat and friends; store in one canonical format
• Input characters: decide whether you accept emoji, accented characters, and right-to-left scripts

5. Fallback for missing translations

Add a new string, forget to translate it in one language, and users see raw keys like "dashboard.title". Decide up front which language to fall back to and how you'll detect gaps.

• Choose a fallback language (for example, English)
• Check in CI that translation files have identical keys across languages

What goes wrong when you skip this

• In the English UI, "Cancel all scheduled jobs" wrapped next to a "Delete" button, misaligning the two and causing mis-clicks
• Notifications built by concatenation produced mixed-language sentences in the English version
• A name field capped at 10 characters, chosen with Japanese names in mind, rejected international users' full names

Each is tedious to find and fix after implementation, yet none would have happened if the requirement had been settled first.

A checklist you can use today

• Have you chosen supported languages and the expansion ratio of the longest one?
• Have you listed fixed-width components?
• Have you banned string concatenation in favor of per-sentence keys?
• Have you committed to a plural-aware mechanism?
• Have you defined input and display formats for names, addresses, dates, and numbers?
• Have you chosen a fallback language and a way to detect missing translations?

During design review, look at screens filled with placeholder text in your longest language. It surfaces expansion problems early.

Putting it into practice with Bugoon

Localization bugs appear in languages the builders don't use day to day, so developers rarely notice them. With the Bugoon widget embedded in your site, QA staff and users working in the English version can point at a broken screen with a screenshot and annotations. Each report automatically records the display language and screen size, so you can reproduce "which language, at which width" without a round of follow-up questions. Reports can be organized through GitHub Issue integration and the Kanban board, and handed to Claude Code or Cursor for fixes through the MCP server.