Building for a global audience means your application must speak multiple languages, display correct date and number formats, and handle cultural nuances. Internationalization (i18n) is the architecture that makes this possible.
This guide covers practical i18n strategies for web applications.
URL strategies
The first decision is how to structure your URLs. Three common approaches exist:
Subdomain: de.example.com, fr.example.com. Requires separate DNS configuration and can be treated as separate sites by search engines. Good for drastically different content per region.
Subdirectory (prefix): example.com/de/, example.com/fr/. The most common approach. Easy to implement, recommended by Google, and preserves link equity.
Query parameter: example.com?lang=de. Not recommended. URLs are less clean, and some search engines may not index all language variants.
Translation management
JSON-based translation files are the standard approach:
{
"common": {
"welcome": "Welcome to our platform",
"cta": "Get started"
}
}
Create a separate file for each language: en/common.json, es/common.json, de/common.json.
Translation libraries:
- next-intl: purpose-built for Next.js, supports both App Router and Pages Router
- react-i18next: most popular React i18n library, mature ecosystem
- lingui: compile-time extraction, smaller bundle size
Key considerations:
- Use interpolation (variables in translated strings), not string concatenation
- Handle pluralization rules (English has two, Arabic has six, Japanese has none)
- Support gender-aware translations where needed
- Extract translation keys automatically to catch missing translations
Date, time, and number formatting
Hardcoding date formats breaks internationalization. Use the Intl API built into modern browsers:
new Intl.DateTimeFormat("de-DE").format(new Date());
// "20.6.2025"
new Intl.NumberFormat("de-DE").format(1234567.89);
// "1.234.567,89"
The Intl API handles formatting rules for every locale without external libraries.
Right-to-left (RTL) support
Languages like Arabic and Hebrew read right-to-left. For CSS, avoid hardcoded left/right values. Use logical properties:
.container {
margin-inline-start: 1rem;
padding-inline-end: 2rem;
}
These automatically flip for RTL languages. Test RTL layouts early — retrofitting RTL support later is significantly more expensive.
SEO for multilingual sites
- Use
hreflangtags to tell search engines which language version to show:<link rel="alternate" hreflang="de" href="https://example.com/de/" /> <link rel="alternate" hreflang="en" href="https://example.com/en/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/" /> - Set
langattribute on the<html>element - Translate metadata (title tags, meta descriptions) for each language
- Avoid automated translation for important content — invest in professional translation
Performance considerations
Loading all translations upfront bloats the bundle. Load only the active locale's translations. Use dynamic imports or a library that lazy-loads translations.
For internationalized static sites, build separate pages for each locale at build time. Next.js supports this with generateStaticParams.
Internationalization is an investment in global reach. Done right, it opens your application to users around the world without compromising quality or performance.
Expanding your web application to international markets? At Vynta implement production-grade i18n systems that handle translations, localization, and multilingual SEO.