What is the difference between an internationalization defect and a translation defect?

### Two families of defect, not one **Internationalization** (often written *i18n*) is the engineering work that makes a single build able to behave correctly for any locale. It means every user-visible string lives in a message catalogue rather than in code; every sentence is one whole message with named placeholders rather than a chain of concatenated fragments; every date, number and money amount goes through a locale-aware formatter; every count goes through the locale's plural rules; every sort and every case-insensitive match goes through a locale-aware comparator; and the storage, transport and rendering path carries a multi-script character set end to end. **Localization** is the per-locale work that follows: producing the translated catalogue, choosing the regional formats and calendar, the currency, the address and name order, the imagery. So an **internationalization defect is a defect in the product**: the code cannot express that locale correctly no matter what text you hand it. A **translation defect is a defect in the content**: the mechanism worked, and the words that came out were wrong, missing, stale or unnatural. ### Why the distinction is operational, not academic Three practical consequences follow, and interviewers are usually probing for these rather than for the definitions. 1. **Routing.** An internationalization defect goes to engineering; a translation defect goes to the linguistic owner of that locale. Sending the wrong one to the wrong owner burns a full cycle and changes nothing. 2. **Blast radius.** One internationalization defect is one code fix that serves every locale, but until it is fixed it is broken in *all* of them, and every added locale inherits it. A translation defect is scoped to one catalogue. 3. **Detection window.** Internationalization defects are findable before a single word is translated — a pseudo-localized build, a scan for literal user-visible strings, a formatter audit, a pass with the process locale forced to something unlike the developer's. Translation defects need real text and usually a native reviewer, which is a slower and more expensive loop. ### The symptom catalogue Typical **internationalization** symptoms: a string hardcoded past the extraction step, so it renders in the source language everywhere; a sentence assembled by concatenation, so the translated word order is unreachable; a count switched between two branches, so locales with more than two plural forms read wrong; a gendered term picked in code from a boolean; a date rendered month-first or a decimal separator assumed; a money amount printed with a fixed symbol, a fixed position and two decimals; a fixed-width container or a truncation counted in bytes that splits a character in half; sorting by raw code-point order; case-insensitive matching that uses the default case mapping; text direction fixed in code; an over-eager input validator that discards the intermediate characters an input method produces; a timestamp stored as local wall-clock text. Typical **translation** symptoms: a mistranslated term; an entry left untranslated in one catalogue; a placeholder deleted or wrongly reordered by the translator; a term inconsistent with the agreed glossary; a string translated without context so an ambiguous source word came out as the wrong sense; a register that is far too formal or too casual for the audience. ### Classify by the fix, not by where you noticed it The recurring argument is truncation. A translated label overflows its container — whose defect? Ask what the fix is. If *no* plausible translation of that message fits, the container assumed source-language length and the fix is in the product: internationalization. If the translator chose a long phrase where a short, accurate one exists, the fix is a shorter term: translation. Sometimes both are true, and the honest report says so and files two items. ### A worked example A utility billing portal went to its first translated build with 2,600 catalogue entries. The bill notice was assembled as three fragments plus a date formatted month-first; a toast reading "Duplicate charge reversed" had never been extracted at all; and the word for the meter device was mistranslated. The incoming report said "the translations are bad". They were not. Three of the four defects were internationalization — the concatenation, the format, the unextracted toast — and exactly one was a translation defect. Routing all four to the translation vendor bought a retranslation cycle that fixed one of them. ### How each family is tested For internationalization: run a pseudo-localized build on every pipeline run; scan for literal user-visible strings; audit every formatting and comparison call site; run the automated suite with a non-default locale so an accidental dependency on the build machine's locale fails loudly; walk the critical flows in a locale that differs on every axis at once — direction, script, decimal separator, date order, plural count, calendar. For translation: in-context linguistic review by a native reviewer, screenshot-in-context review of the real screens, an automated check that every placeholder in the source entry survives into the translated entry, and a check for entries still sitting in the source language.