Internationalization

Same three facts, different renderings — the German button runs noticeably longer than English, and the Japanese one, despite carrying far fewer characters, comes out about as long since each full-width CJK glyph renders wider than a Latin letter; the date and price formats are restructured in addition to a simple translation.

Problem

A site built for one language and region has assumptions about URL structure, content storage, text length, reading direction, number/date/currency formats, and even legal obligations baked into it. Reaching international markets means re-engineering all of that, not just translating the visible copy — and getting it wrong forces retroactive engineering work far more expensive than building for it from the start.

Reaching international markets means re-engineering all of that, not just translating the visible copy — and getting it wrong forces retroactive engineering work far more expensive than building for it from the start.

Solution

Internationalization (abbreviated i18n) is the practice of designing a site so it can be adapted for different languages, regions, and cultures without re-engineering the core product. Localization (l10n) is the subsequent act of adapting a specific locale’s content and formatting.

Signal language through URL structure

Sites serving multiple locales need a URL strategy that is both machine-readable (for search engines) and human-understandable:

Country-code top-level domains (ccTLDs) — e.g., example.fr, example.de — provide the strongest geo-targeting signal but require separate domain registrations and distinct infrastructure per country.
Subdirectories — e.g., example.com/fr/ — are operationally simpler, consolidate domain authority, and are preferred for most sites.
Subdomains — e.g., fr.example.com — are treated by search engines similarly to separate sites; avoid unless there is a specific infrastructure reason.

Add `hreflang` tags to prevent duplicate-content penalties

hreflang tags tell search engines which page is the canonical version for each language/region combination, preventing duplicate-content penalties. Every localized page should include hreflang annotations for all its equivalents.

<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Set up a content management system (CMS) and translation infrastructure

The CMS must support multi-language content management — the ability to store, retrieve, and edit content independently per locale — before localization work can begin. Retrofitting a monolingual CMS is significantly more expensive than choosing one that supports i18n from the start.

Design for text expansion

Translated content is routinely 20–40% longer or shorter than the English source — German and Finnish text expands; Chinese text contracts. UI layouts that depend on fixed text widths break under translation:

Use flexible/fluid layouts, not fixed-width text containers (see Responsive Web Design)
Avoid truncation in buttons, navigation labels, or other key UI strings — truncation obscures meaning and the degree of truncation varies by locale
Test with placeholder “long strings” during layout design, before translations exist

Support right-to-left (RTL) languages

Arabic, Hebrew, Persian, and Urdu are written right-to-left. RTL support is not simply mirroring text — it requires:

Declaring dir="rtl" on the HTML element or specific containers
Ensuring that layout (sidebars, reading order, iconography direction) mirrors logically, not only typographically
Testing with actual RTL users — automated mirroring handles most cases but misses culturally-specific conventions

<!-- Default, left-to-right -->
<html lang="en" dir="ltr">

<!-- Arabic, right-to-left -->
<html lang="ar" dir="rtl">

Decide early whether RTL is in scope; adding it after a site is built is a significant rework, not a flag flip.

Two identical app layouts side by side: the left, labeled dir="ltr", has its icon sidebar on the left, body text reading left-to-right, and a "Continue →" button in the bottom right; the right, labeled dir="rtl", has the same sidebar moved to the right, body text reading right-to-left, and a "← Continue" button in the bottom left Every element that implied a direction — the sidebar, the reading order, the button and its arrow — flips as a set; translating the words alone would leave the layout pointing the wrong way.

Direction is only one axis of script variation: typeface selection and spacing conventions also vary across scripts (Latin, CJK — Chinese, Japanese, Korean — Arabic, Devanagari), and text rendering requirements differ from those of Latin-script languages.

Localize numbers, dates, and currency

Numbers, dates, times, and currency are formatted differently by locale and must be localized, not merely translated:

Currency: symbol placement varies (€100 vs. 100 €); decimal and thousands separators vary (1,000.00 vs. 1.000,00); always show the currency code (USD, EUR, JPY) for international audiences in addition to the symbol
Dates: MM/DD/YYYY (United States) vs. DD/MM/YYYY (most of Europe) vs. YYYY-MM-DD (ISO 8601); ambiguous formats (06/07) read as June 7 or July 6 depending on locale; use unambiguous formats or spelled-out month names for user-facing dates
Time: 12-hour vs. 24-hour convention; time zone display and conversion
Phone numbers: formatting conventions differ significantly by country; avoid enforcing a single input mask
Address forms: field sets and their labels are themselves locale-specific, not just the values entered into them — a “Zip Code” field means nothing in a country that uses “Postal Code,” and a “State” field has no equivalent at all in many countries. Adapt the field set and its labels to the selected country rather than leaving an inapplicable field empty.

Two "Shipping Address" forms for the same Japan address: on the left, labeled BEFORE, US-style labels ("Zip Code," an empty "State" field) alongside Country, City, and Street address; on the right, labeled AFTER, the State field is removed entirely and "Zip Code" is relabeled "Postal Code," with the same Country, City, and Street address values An empty field a customer can’t fill in is still a form that doesn’t fit their country — removing it is part of localizing, not an edge case to tolerate.

Plan the translation and localization process

Machine translation alone is not a substitute for a human translator: software cannot resolve context-dependent ambiguity (a word like “cook” used as a navigation label could mean the verb, a job title, or a surname, and a machine will commit to one reading regardless of which was intended). Hire translators with genuine domain and cultural familiarity with the target audience, not just language fluency — a technically fluent but culturally uninformed translation still produces embarrassing mistakes.

Machine translation alone is not a substitute for a human translator: software cannot resolve context-dependent ambiguity (a word like “cook” used as a navigation label could mean the verb, a job title, or a surname, and a machine will commit to one reading regardless of which was intended).

Choose a localization management structure deliberately: centralized management gives every product area access to shared translation services but lacks each area’s domain expertise; decentralized management taps domain expertise spread across the organization but sacrifices cross-team consistency, since teams in different locales may not know what terminology choices other teams have already made. A hybrid — central infrastructure with local review — is the common compromise.

Adapt culturally, beyond translation

Translation is necessary but not sufficient — full localization also means:

Use familiar terminology: acronyms and institutions taken for granted domestically (e.g. a country-specific tax agency or sports league) are often unrecognized abroad; prefer terms that translate as concepts, not just as words.
Respect color and symbol meaning: color associations are not universal — white, not black, is the color of mourning in China and Taiwan — so a color or icon chosen for its meaning in one market can carry an unintended, even offensive, connotation in another. See Color Theory for the broader case against treating any color scheme as a universal design constant.
Plan around holidays, customs, and support coverage: staffing for customer-facing functions (support, moderation) needs to account for the target locale’s own holiday calendar, not just the home market’s.
Tailor services, not just words: local food preferences, shopping habits, and other behavioral differences may call for changes to the product or service itself, discoverable through the same on-the-ground research techniques used for any other audience.

color associations are not universal — white, not black, is the color of mourning in China and Taiwan — so a color or icon chosen for its meaning in one market can carry an unintended, even offensive, connotation in another

Account for legal and jurisdictional differences

Operating across borders can trigger obligations well beyond translation: import/export and customs rules affecting what can be sold or shipped where, foreign sales-tax regimes, and content restrictions that vary by country (some jurisdictions ban specific categories of content outright, independent of what’s legal in the site’s home market). Data-protection law is frequently stricter abroad than at home — the EU, for instance, historically gave individuals broader rights to access and manage data held about them than U.S. law required at the time — so Fair Information Practices and a site’s Privacy Policy may need locale-specific variants rather than one global version.

Patterns

Principles

Processes

Web Site Development Process

Standards

Fair Information Practices

Sources

The Design of Sites: Pattern Group D — Writing and Managing Content (Pattern D10) is the source for the translator/localization-management practices, the cultural-adaptation-beyond-translation guidance, and the cross-border legal and jurisdictional considerations.