Internationalization and localization at scale

Building products for many languages and regions: locales, translation pipelines and string management, plural and gender rules, right-to-left layouts, Unicode and text handling, currencies and number formats, regional content and pricing, search across languages, and serving localized content efficiently.

Reading is half of it. See this used in a real interview: walk through Design Airbnb →

A product used in 50 countries must speak 30 languages, show prices in local currencies, sort names correctly, lay out Arabic and Hebrew right to left, and follow local rules. Internationalization (i18n) is designing the system so this is possible; localization (l10n) is doing it for each market. It rarely gets its own interview question, but global products (Airbnb, Netflix, marketplaces) are expected to handle it, and the design choices affect storage, search, caching and APIs.

Locales

A locale combines language and region (pt-BR, pt-PT, en-GB), which affects spelling, formats and content. Determine it from user settings first, then the app or browser language, then location as a weak hint. Store the user's locale and time zone in their profile, and pass the locale through APIs explicitly. See time zones and dates.

Strings and translation pipelines

• No user-visible text hardcoded in code; use message keys with source strings in a resource catalogue.
• Use a message format that supports variables, plurals and gender (ICU MessageFormat): "{count, plural, one {# night} other {# nights}}". Languages have different plural rules (Arabic has six forms), so string concatenation in code always breaks somewhere.
• A translation pipeline: new strings are extracted on merge, sent to a translation management system (human translators, machine translation with review), and translated bundles are published back.
• Fallbacks: missing pt-BR falls back to pt, then the default language, never to a raw key.
• Ship translations independently of code where possible (fetched bundles with versioning and caching), so fixes do not need an app release. See mobile system design.

User-generated content

Listings, reviews and messages are written in many languages:

• Store the original language with each item.
• Offer machine translation on demand, caching results per (item, target language), and label translated text.
• Allow hosts or sellers to provide their own translations. See Design Airbnb.

Text handling

• Use UTF-8 everywhere: databases, APIs, files. Count and truncate by user-perceived characters (grapheme clusters), not bytes, or emoji and accented letters break.
• Normalise Unicode (NFC) before comparing or indexing, so visually identical strings match.
• Collation: sorting and case-insensitive comparison depend on locale; use locale-aware collation in databases and code.
• Watch for lookalike characters in usernames and domains (homograph attacks). See trust and safety.

Layout

• Right-to-left languages mirror layouts; use logical properties (start and end, not left and right) in UI code.
• Translations can be 30 % longer or much shorter than English; design flexible layouts.
• Fonts must cover the scripts you support.

Numbers, currencies and units

• Format numbers, dates, currencies and units with locale-aware libraries: "1.234,56 €" versus "€1,234.56".
• Store money as integer minor units plus a currency code; convert for display with dated exchange rates, and charge in a defined currency. See payments and ledgers.
• Regional pricing is a business decision; make prices per market, not computed conversions, when required.
• Units (km versus miles, Celsius versus Fahrenheit) follow the locale or user preference.

Regional content and rules

Different catalogues per country (licensing in streaming), different legal requirements (consent, age ratings, data residency), different payment methods and address formats. Model availability per region and enforce it at the API and CDN level. See Design Netflix and privacy and data deletion.

Search across languages

• Language-specific analyzers (stemming, tokenisation; Chinese and Japanese need word segmentation).
• Index content per language, or multilingual embeddings for cross-language matching. See how Elasticsearch works and vector search and RAG.
• Transliteration and diacritics handling ("Sao Paulo" matching "São Paulo"). See Design Yelp.

Serving localized content

• Cache keys must include locale (and region where content differs); otherwise users get pages in the wrong language. Use Vary carefully, or put the locale in the URL path. See HTTP caching.
• Localized URLs (/fr/...) with hreflang tags help search engines index the right version.
• Notifications and emails render in the recipient's locale, not the sender's. See Design a Notification System.

In the interview

One or two sentences show awareness: "UI strings use ICU message keys translated through a pipeline and fetched as versioned bundles; user content stores its language with on-demand cached machine translation; prices are per-market in integer minor units; caches and URLs are keyed by locale; search uses language-specific analyzers."

Checklist

• Locale from settings, passed explicitly; stored with time zone.
• Message keys with ICU plurals and gender; translation pipeline and fallbacks.
• UTF-8, Unicode normalisation, locale-aware collation, grapheme-aware truncation.
• RTL-aware, flexible layouts.
• Locale-aware formatting; integer money with currency; per-market pricing.
• Regional availability and rules; language-aware search.
• Locale in cache keys and URLs; notifications in the recipient's locale.