Localization-Ready Copy (i18n/L10n)

The full lesson

Shipping a product in a new language is rarely just a translation job. It exposes every assumption baked into your original copy. Date formats, pluralization rules, reading direction, text expansion, honorifics, and culturally loaded metaphors can all break a carefully designed interface the moment a translator touches it. Writing localization-ready copy means making those assumptions explicit and structural — before a single string is handed off.

Why “Just Translate It” Fails

The typical workflow goes like this: finalize English copy, hand it to a translation vendor, then fix whatever breaks in QA. This approach is expensive and slow. Text that expands 40% in German overflows buttons. Hard-coded ordinals like “1st,” “2nd,” “3rd” don’t map cleanly to many Romance and Slavic languages. A phrase like “hit the ground running” is idiomatic in English and nearly untranslatable — a literal rendering in Japanese or Arabic is meaningless or absurd.

The root problem is structural. English was treated as the product’s source of truth instead of as one possible rendering of an underlying idea. Localization-ready copy treats every string as an expression of a language-neutral intent — something that can be expressed correctly in any target locale.

Text Expansion and Layout Contracts

The most visible localization problem is text expansion. English tends to be one of the most compact languages in the Latin script family. When you translate into other languages, strings routinely grow:

Every button, label, tab, and tooltip you write creates an implicit layout contract. “Save” (4 characters) becomes “Enregistrer” (11 characters) in French. A 90 px wide button that fits “Save” will clip “Enregistrer” unless the layout can flex.

The modern practice is to design with intrinsic CSS — buttons sized by their content with min/max constraints, not fixed widths. Container queries let components respond to their own size rather than the viewport, which is exactly what localizable components need. Avoid fixed-width text containers wherever possible. When a fixed width is unavoidable (like a tab bar), agree on a maximum character budget per locale with your localization team.

Writing Strings That Translate Well

Most localization friction starts with how English copy is written. These patterns consistently cause problems downstream.

Avoid idioms and cultural metaphors

Phrases like “kick the tires,” “get the ball rolling,” and “under the hood” are opaque to non-native speakers. In literal translation they’re actively misleading. Use plain-language equivalents instead: “try it out,” “get started,” “advanced settings.”

Don’t split sentences across multiple strings

A common engineering pattern builds a sentence from parts to avoid duplication:

"Your " + accountType + " account will expire in " + days + " days."

This causes several problems. Word order changes dramatically across languages — in German, the verb often lands at the end of a clause. Splitting a sentence into segments prevents the translator from reordering words the way the target language requires. The result is broken copy.

Use a single string with named placeholders instead:

"Your {accountType} account will expire in {count} {unit}."

Named placeholders (not positional %s or %1$s) are the current standard. They survive reordering and make translator intent clear. Most modern i18n libraries — ICU MessageFormat, Fluent, i18next with named interpolation — support this pattern natively.

Handle plurals with a pluralization framework

English has two plural forms: singular and plural. Many languages have far more. Russian has four distinct plural forms. Arabic has six. Polish distinguishes between small numbers (2–4), medium numbers (5–20), and large numbers.

Writing count + " items" and switching to "item" when count equals 1 is brittle. Use the ICU MessageFormat plural syntax:

{count, plural,
  one {# item}
  other {# items}
}

Localization tools that support ICU MessageFormat — including most enterprise TMS platforms — will surface the correct plural categories for each target language and prompt translators to provide all required forms. Never write pluralization logic in component code. That logic belongs in the string resource.

Don’t concatenate dynamic values into nouns with grammatical gender

In many languages, adjectives, articles, and past-participle verbs must agree in gender with the noun they modify. If “deleted” is applied to a noun that changes (file, folder, message, contact), you cannot reuse the same translated word. Plan for gender-aware strings, or design copy that avoids the dependency altogether.

Dates, Times, Numbers, and Units

Formats that feel “standard” in English are locale-specific conventions. Hard-code them and they’ll be wrong in every other market.

Never format dates, times, numbers, or currency inside UX copy strings. Always pass raw values to the browser’s Intl API (or its equivalent in your stack) and let the runtime produce a locale-appropriate representation. Writing “June 7, 2026” in a string that goes through translation is a mistake — a translator must manually reformat it, and QA must verify it per locale.

// Modern: locale-aware, no hardcoded format
new Intl.DateTimeFormat(locale, { dateStyle: 'long' }).format(date)

// Outdated: locale-agnostic, always wrong in non-US locales
"June " + day + ", " + year

The same principle applies to units. A product targeting the United States, United Kingdom, and continental Europe needs to handle both imperial and metric units. Drive this through locale configuration, not copy.

Right-to-Left (RTL) Considerations

Arabic, Hebrew, Farsi, and Urdu are written right-to-left. This affects more than text direction — it affects the entire spatial logic of the interface. Navigation hierarchies run right-to-left. Icon arrows pointing “forward” should point left, not right. Progress bars fill from right to left.

From a copy perspective:

• Avoid directional instructions like “click the button on the left.” Use positional names (“click Start”) or rely on icons with text labels.
• Don’t embed directional arrows or chevrons in copy strings. Use separate icon components that can be mirrored.
• Test all copy in an RTL context. Many RTL problems only become visible when strings are long enough to wrap, or when mixed-direction text (a URL or code snippet inside Arabic prose) causes unexpected bidirectional rendering.

The CSS logical properties system — margin-inline-start instead of margin-left — is the current standard for layout. But copy itself must not create directional assumptions either.

Tone, Formality, and Cultural Register

Translation is not just word substitution — it is cultural adaptation. The same brand voice may need different formal registers across markets.

• German and Japanese interfaces typically use formal registers (Sie/keigo) that have no direct English equivalent. A casual “Hey there! Let’s get started” may read as unprofessional or strange in those markets.
• Brazilian Portuguese and European Portuguese differ enough that they are often treated as separate locales with different translators.
• Some markets expect explicit hierarchy acknowledgment; others prefer the flat conversational style common in US tech products.

Document your brand voice principles in a way that describes the intent behind the tone — respectful, encouraging, direct — rather than English-specific constructions. A good localization brief includes: desired emotional register, appropriate and inappropriate vocabulary domains, and examples of on-brand and off-brand phrasing in the source language. This lets translators apply equivalent judgment rather than just mirroring surface features.

Strings That Should Not Be Translated

Not all strings in an interface are copy. Some should be explicitly marked as non-translatable:

• Proper nouns and brand names — product names, feature names, and trademarks. “Figma,” “iCloud,” “GitHub” do not change across locales.
• Technical identifiers — error codes, API endpoint names, keyboard shortcuts (which may or may not be remapped — that’s a separate decision).
• Legal terms of art — some legal phrases must remain in the original language for validity.

Most modern localization management systems — TMS platforms like Phrase, Lokalise, Crowdin — support “do not translate” (DNT) metadata at the string level. Set this at the source rather than relying on translators to recognize brand names in context.

Building a Localization-Ready Content Model

Writing individual strings well is necessary but not sufficient. A scalable approach requires a content model that treats localization as a first-class concern.

1. Externalize all strings from day one. No hard-coded copy in components. Use a string resource file (en.json, or an ICU MessageFormat catalog) from the first commit.
2. Name strings semantically. settings.account.delete.confirm is maintainable; string_1847 is not. Good key names help translators understand context without needing a screenshot.
3. Attach context metadata to every string. Include: the UI location, max character budget (if constrained), a screenshot or component reference, and any placeholders with their expected values and types. Missing context is the single largest source of translation errors.
4. Use a TMS with translation memory. Translation memory (TM) surfaces previously translated strings when the source changes slightly — reducing cost and ensuring consistency. “Save,” “Cancel,” and “Delete” should resolve identically across the whole product.
5. Establish a locale coverage policy. Decide upfront which locales the product targets. Note that “Spanish” may mean es-ES, es-MX, or es-AR — three different locale codes with meaningful differences. Decide which locales get professional translation vs. community translation.

Localization in the Design and Writing Process

Localization-readiness is not a QA phase. It is a design constraint you apply from the very first draft.

• During content design: write placeholder-first, not idiom-first. When you draft copy, ask “would a non-native speaker understand this literally?” If not, rewrite it.
• During design review: include a localization stress test. Many teams apply a “40% text expansion” overlay in Figma to catch layout failures before development begins.
• During dev handoff: make string keys, context notes, and character limits part of the component spec — not an afterthought.
• Post-launch: treat locale-specific support tickets as a content feedback loop. Users who report confusing translations are surfacing strings that lacked sufficient context in the original brief.