Multi-language websites: URLs, formats and editorial control

Illustration for Efficient Multi-Language Support for Global Reach: Abstract visualization of Implementing Multi-Language Support in Web Applications, layered paper cut
Illustration for Efficient Multi-Language Support for Global Reach: Abstract visualization of Implementing Multi-Language Support in Web Applications, layered paper cut

Multi-language support requires translated content, a consistent URL policy and correct formatting. Browser language is a preference signal, not a reliable substitute for the user's explicit choice. Formatting a price for another locale does not convert its currency.

Keep each language version addressable

Provide a language switcher that preserves the page's meaning where an equivalent exists. Do not force a redirect that prevents a reader or crawler from opening a chosen language. Google localized site versions documents hreflang annotations for localized variants, including self-references and reciprocal alternatives.

ItemKeep stableLocalize or review
ProductInternal ID and specificationDescription and display labels
PriceAmount and actual currencyNumber formatting
Content pageEquivalent-page mappingText, metadata and terminology
FormRequired data and validationLabels and understandable errors

A complete price-formatting example

The following JavaScript runs in Node.js or a browser console. The amount is an illustrative value; no conversion takes place.

const amount = 1234.5;
const currency = 'EUR';
const supported = new Set(['en-GB', 'de-DE', 'hr-HR']);

function formatPrice(locale) {
 const selected = supported.has(locale)? locale: 'en-GB';
 return new Intl.NumberFormat(selected, {
 style: 'currency', currency,
 }).format(amount);
}

console.log(formatPrice('de-DE')); // 1.234,50 €
console.log(formatPrice('unsupported')); // €1,234.50

MDN Intl.NumberFormat describes locale-sensitive currency formatting. Spacing may use Unicode characters, so tests should inspect formatting parts rather than assume plain ASCII spaces.

Assign responsibility for content changes

When the source page changes, mark translations needing review. Legal wording, delivery terms and technical specifications require more than word-for-word machine translation. Avoid changing commercial terms merely because the display language changed.

What should release testing include?

Direct access to each language URL, the switcher, form errors, long labels and missing translations. Verify canonical and alternate URLs without claiming a ranking benefit from annotations alone. For web development, prepare language owners and equivalent-page mapping alongside the text.