Quiz

What kind of things must you be wary of when designing or developing for multilingual sites?

Topics
HTMLInternationalization

TL;DR

Multilingual design is more than translating strings. Use valid BCP 47 language tags, declare lang and dir in HTML, give users a persistent language switcher, keep whole messages translatable, format locale-sensitive values with Intl, and design for text expansion and different writing directions. Use stable locale-specific URLs and reciprocal hreflang links when localized pages should be indexed.


What kind of things must you be wary of when designing or developing for multilingual sites?

Internationalization prepares an application for multiple languages, scripts, regions, and cultural conventions. Localization supplies the content and rules for a particular audience.

Declare language and direction in markup

Set the document's default language on <html> and mark passages that switch languages. Screen readers, spellcheckers, search engines, and font selection can use this information.

<html lang="ar" dir="rtl">
<p>مرحبا</p>
<p lang="en" dir="ltr">Welcome</p>
</html>

Use BCP 47 tags such as en, en-GB, or zh-Hant. Language and direction are separate: lang does not automatically set dir. Use dir="auto" for user-generated text whose direction is unknown, and prefer CSS logical properties such as margin-inline-start over physical left and right properties.

Let users control the locale

Accept-Language can provide an initial hint, but it may reflect a shared device, proxy, or browser setting rather than the user's choice. IP geolocation is an even weaker language signal. Offer an obvious language switcher, preserve the selection, and avoid repeatedly forcing redirects.

Do not treat language, region, currency, and country as interchangeable. For example, a user may choose English while living in Japan and paying in Japanese yen.

Translate complete messages

Do not assemble sentences from translated fragments such as "The date is " + date. Word order, plural forms, grammatical gender, and surrounding punctuation differ between languages. Give translators complete messages with named placeholders and use the message-formatting features of the chosen localization system.

Format values with locale-aware APIs rather than handwritten patterns:

const price = new Intl.NumberFormat('de-DE', {
style: 'currency',
currency: 'EUR',
}).format(1234.5);
console.log(price); // Formatting and spacing are locale-dependent.

Tests should assert the meaningful value or selected locale, not brittle punctuation that can vary between runtime data versions.

Design flexible layouts

  • Expect translated labels and headings to expand or wrap.
  • Avoid fixed heights for text containers and test long words, narrow viewports, and browser zoom.
  • Keep text as text instead of baking it into images.
  • Use fonts that cover the required scripts and verify fallback rendering.
  • Check focus order, keyboard interaction, form errors, accessible names, and truncation in every supported direction.
  • Do not communicate meaning through color, icons, or cultural metaphors alone.

Give localized pages stable URLs

Locale-specific paths such as /en/products and /fr/products are easier to share, cache, index, and debug than a single URL whose language changes silently. If pages are equivalent localized versions, add reciprocal rel="alternate" links with hreflang and optionally an x-default fallback. Use hyphenated BCP 47 values such as en-US, not locale-library identifiers such as en_US, in HTML.

Localization should be tested with actual target-language content and native or professional review; machine translation and pseudolocalization are useful checks but not final linguistic validation.

Further reading

Exercises

Check your understanding
Beta
Check your understanding Exercise
Check your understanding Exercise

A product is adding Arabic and German to an English-only interface. Describe the design and implementation review you would conduct before launch.