Multi-Language Websites: A Technical Guide to Internationalization

URL Strategy: The First Decision

How you structure URLs for different languages affects SEO, user experience, and implementation complexity. There are three main approaches.

Subdirectories (Recommended for Most Projects)

example.com/         (English - default)
example.com/es/      (Spanish)
example.com/fr/      (French)

Advantages:

• Simple to implement and maintain
• All languages share domain authority
• Easy to manage with most hosting setups
• Clear, intuitive URL structure

This is the approach we recommend for most projects. It balances simplicity with SEO effectiveness.

Subdomains

en.example.com
es.example.com
fr.example.com

Advantages:

• Clear separation between language versions
• Can host different languages on different servers

Disadvantages:

• Domain authority is split across subdomains
• More DNS configuration and maintenance
• Google treats subdomains as somewhat separate sites

Country-Code Top-Level Domains (ccTLDs)

example.com    (English)
example.es     (Spanish)
example.fr     (French)

Advantages:

• Strongest geo-targeting signal for search engines
• Clear to users which regional version they are on

Disadvantages:

• Most expensive to maintain (separate domain registrations)
• Domain authority does not transfer between TLDs
• Requires separate SEO efforts for each domain

Implementing Hreflang Tags

Hreflang tags tell search engines which language and regional version of a page to serve to different users. Getting these right is critical for multilingual SEO.

The Rules

Every page must include hreflang tags pointing to all language versions, including itself:

The x-default value specifies the fallback page for users whose language is not specifically targeted.

Common Hreflang Mistakes

Missing return links. If page A references page B in its hreflang, page B must also reference page A. Missing return links cause Google to ignore the annotations entirely.

Incorrect language codes. Use ISO 639-1 language codes (en, es, fr) and optionally ISO 3166-1 Alpha-2 country codes (en-US, en-GB, es-MX). Common errors include using "uk" for Ukrainian (it should be "uk" but "uk" is also the country code for United Kingdom — use "uk" for language, "en-GB" for British English).

Pointing to non-existent pages. Every URL in your hreflang annotations must return a 200 status. Do not include hreflang references for pages that do not exist in a particular language.

Using hreflang with canonical conflicts. If a page has a canonical tag pointing to a different URL, make sure hreflang annotations match the canonical URLs.

Translation Architecture

Translation Files

The most common approach for application text (buttons, labels, error messages, navigation) is key-based translation files:

// en.json
{
  "nav.home": "Home",
  "nav.services": "Services",
  "nav.contact": "Contact Us",
  "hero.title": "We Build Smarter Websites"
}
// es.json
{
  "nav.home": "Inicio",
  "nav.services": "Servicios",
  "nav.contact": "Contáctenos",
  "hero.title": "Construimos Sitios Web Más Inteligentes"
}

Framework Support

Modern frameworks have mature i18n libraries:

• Next.js: next-intl or next-i18next
• React: react-intl (FormatJS) or i18next
• Vue: vue-i18n
• Angular: Built-in i18n support

These libraries handle not just text translation but also date formatting, number formatting, pluralization rules, and other locale-specific concerns.

Content Translation

For CMS content (blog posts, product descriptions, marketing pages), translations are typically managed at the CMS level. Headless CMS platforms like Contentful and Sanity have built-in localization features that store translated content alongside the original.

For static content sites, translation files per locale work well when combined with a static site generator or server-side rendering framework.

Locale Detection and Routing

How to Determine the User's Preferred Language

1. URL-based (primary) — If the user navigates to /es/, serve Spanish. This is the most reliable and transparent method.
2. Accept-Language header — The browser sends the user's language preferences. Use this for initial redirect decisions on the root URL.
3. Geolocation — Infer language from the user's geographic location. Less reliable (a Spanish speaker in the US still speaks Spanish) but useful as a supplementary signal.
4. User preference — Store the user's explicit choice in a cookie or account settings. This should always override other detection methods.

The "As Needed" Locale Prefix Pattern

A clean approach used by many modern websites:

• Default language (English) lives at the root: example.com/about
• Other languages use a prefix: example.com/es/about

This keeps English URLs clean while making other languages explicit. The framework handles routing transparently.

Language Switcher Design

Every multi-language page should have a language switcher. Best practices:

• Display language names in their native script (Español, not Spanish; Deutsch, not German)
• Navigate to the same page in the selected language, not the homepage
• Remember the user's choice for subsequent visits
• Make the switcher easily discoverable (typically in the header or footer)

Handling Right-to-Left (RTL) Languages

If you support Arabic, Hebrew, Persian, or other RTL languages, your entire layout needs to mirror.

CSS Logical Properties

Modern CSS provides logical properties that automatically adapt to text direction:

/ Instead of: /
margin-left: 1rem;
padding-right: 2rem;
text-align: left;
/ Use: /
margin-inline-start: 1rem;
padding-inline-end: 2rem;
text-align: start;

Logical properties flip automatically when the document direction changes, eliminating the need for separate RTL stylesheets.

HTML Direction Attribute

Set the dir attribute on your HTML element:

This tells the browser and CSS to render content right-to-left.

Text Expansion and Contraction

Different languages take different amounts of space to say the same thing. German text is typically 30 percent longer than English. Chinese can be 50 percent shorter. Japanese characters are wider individually but text can be more compact overall.

Design for Flexibility

• Use flexible layouts that accommodate text of varying lengths
• Test your UI with long translations (German is a good stress test)
• Avoid fixed-width buttons that might truncate text
• Use CSS text-overflow for graceful handling of unexpectedly long strings
• Never truncate translated text without providing access to the full text

Date, Number, and Currency Formatting

Formatting conventions vary dramatically between locales:

| Format | US English | German | Japanese |
|--------|-----------|--------|----------|
| Date | 02/04/2026 | 04.02.2026 | 2026年2月4日 |
| Number | 1,234.56 | 1.234,56 | 1,234.56 |
| Currency | $1,234.56 | 1.234,56 € | ¥1,234 |

Use the Intl JavaScript APIs (Intl.DateTimeFormat, Intl.NumberFormat) to handle these automatically based on the user's locale.

Testing Multi-Language Implementations

Pseudo-Localization

Before actual translations are ready, use pseudo-localization to test that your UI handles different languages correctly. Pseudo-localization transforms English text to look different while remaining readable:

"Settings" becomes "[Šéttîñgš]" — you can still read it, but you can verify that non-ASCII characters render correctly and that text expansion is handled.

Automated Testing

• Verify all pages in all languages return 200 status codes
• Check that hreflang tags are present and correctly cross-referenced
• Validate that locale-specific formatting is applied correctly
• Test language switching navigates to the correct translated page

Manual Testing

• Have native speakers review translated content for naturalness
• Test the user journey in each language end-to-end
• Verify that forms accept input in all target character sets
• Check that search functionality works with non-Latin scripts

How Kukalaya Addresses This

Kukalaya builds multi-language websites using next-intl with the "as-needed" locale prefix pattern — English at the root, other languages at clean subdirectory paths. We implement proper hreflang tags, locale-aware routing, structured translation workflows, and locale-specific formatting out of the box. Our own site serves English and Spanish with full SEO optimization for both. Learn about our services.

The Investment That Opens Markets

Building a multi-language website is an investment in market expansion. When done correctly, it is one of the most cost-effective ways to reach new customers. A single website serving five languages reaches a significantly larger audience than five separate monolingual sites.

The technical foundations matter. Getting URL structure, hreflang tags, locale routing, and formatting right from the start prevents costly rework later. And as your language coverage expands, a solid i18n architecture makes adding each new language straightforward rather than a major project.

Your website can speak your customers' language — literally. The technical path is well-established. The competitive advantage awaits.