Multilingual Corporate Websites: How to Reach International Clients

#softwin #ai #websitedevelopment #digitalmarketing

Most articles about "reaching international clients" focus on translation vendors and marketing copy. This one focuses on the build side — the technical decisions that determine whether a multilingual site actually gets indexed correctly, performs well for every target region, and doesn't break when a new locale, such as Arabic or Japanese, gets added later.

This guide reflects the general approach the SoftWin web development team follows when building multilingual corporate websites for clients: get the architecture right first, then layer content and translation on top.

Start with URL architecture, because it's hard to change later

Three common patterns, each with real tradeoffs:

Subdirectories:   example.com/en/  example.com/de/  example.com/fr/
Subdomains:       en.example.com   de.example.com   fr.example.com
ccTLDs:           example.com      example.de       example.fr

Subdirectories are the pragmatic default for most corporate sites. All locales share domain authority, they're straightforward to deploy from a single app or CMS, and analytics stay unified under one property.

Subdomains make sense when regional teams manage content independently or run on separate infrastructure or CMS instances — but SEO authority is split across subdomains, and DNS/certificate overhead increases.

ccTLDs (.de, .fr, .jp) send the strongest local-relevance signal to both users and search engines, but come with real operational cost: separate domain registration, hosting/CDN considerations, and no shared authority with the main domain. This approach is typically only justified for large enterprises with dedicated regional operations.

Whichever structure is chosen, it's worth deciding before launch — migrating URL structure after a multilingual site has been indexed is a significant SEO project on its own (redirects, hreflang rewrites, re-crawling), not a quick refactor.

hreflang: the tag that's most often implemented incorrectly

hreflang tells search engines which language and regional version of a page to serve to which searcher. Missing or malformed hreflang is one of the most common reasons a fully translated site still shows the original-language version to non-native searchers.

Basic implementation in <head>:

<link rel="alternate" hreflang="en" href="https://example.com/en/pricing" />
<link rel="alternate" hreflang="de" href="https://example.com/de/pricing" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing" />

A few details that are easy to get wrong:

Every page needs to reference all of its language variants, including itself (self-referencing hreflang).
x-default matters — it acts as the fallback for languages or regions that aren't explicitly targeted.
Region-specific codes (en-GB vs. en-US, pt-BR vs. pt-PT) differ from language-only codes (en, pt) — the choice depends on whether content actually differs by region or only by language.
On a JS framework, these tags are best generated programmatically from the routing configuration rather than maintained by hand per page — hreflang drift, where new pages are added without updated tags, is a common source of silent international SEO issues.

i18n libraries worth knowing

Depending on the stack, some commonly used options for the string and content management layer:

next-intl or next-i18next — for Next.js, integrates with routing and handles locale-based paths cleanly.
react-i18next / i18next — framework-agnostic, mature ecosystem, includes pluralization and interpolation support.
FormatJS (react-intl) — strong ICU message format support, useful for pluralization and date/number formatting across locales.
vue-i18n — the standard choice in the Vue ecosystem.

These libraries handle the engineering side — swapping strings, formatting dates, numbers, and currency per locale, and handling pluralization rules, which vary more across languages than is often assumed. They do not address translation quality on their own; that still requires professional or hybrid (machine translation plus human review) translation.

RTL support

If Arabic or Hebrew is on the roadmap, right-to-left support involves more than flipping text direction. It typically touches:

dir="rtl" on the <html> element for the relevant locale
Mirrored layouts: navigation, icons, form fields, and progress indicators
CSS logical properties (e.g. margin-inline-start instead of margin-left) rather than hardcoded left/right values, which reduces rework later
Testing with actual native RTL content rather than mirrored placeholder text, since mixed-direction text (for example, Arabic text containing a Latin-script brand name or a number) can expose layout issues that don't appear with placeholder content

Details that are easy to overlook

Currency and number formatting — using Intl.NumberFormat rather than manual string concatenation avoids locale-specific formatting bugs (decimal versus thousands separators vary by locale, not only by currency).
Date formatting — Intl.DateTimeFormat, for the same reason. Date-order ambiguity (day/month vs. month/day) is a recurring source of user confusion when hardcoded.
Font support — confirming the type stack actually covers the character sets being targeted (CJK, Cyrillic, Arabic script) avoids silent fallback to a system font, which breaks visual consistency.
Text expansion — translated strings can run noticeably longer than their source-language equivalents in some languages, and UI tightly fitted to the original text can break once translated. Designing with expansion room in mind from the start avoids rework.
Metadata per locale — title tags, meta descriptions, and Open Graph text should be translated and researched per language, not only the visible body copy, since search behavior differs by language and market.

A reasonable rollout sequence

Lock in URL architecture (subdirectories, in most cases) and implement hreflang correctly from the start.
Select a small number of target locales based on demand data.
Wire up an i18n library and externalize all strings, including ones in error messages, transactional emails, and generated documents, which are often missed.
Handle locale-aware formatting (Intl.*) for currency, dates, and numbers before content is finalized.
Use professional or hybrid translation for content, prioritizing legal, pricing, and contact pages first.
QA with real native-language content, including RTL where applicable, rather than placeholder text.

A multilingual corporate website is as much an engineering problem as a translation one. Getting the architecture right early makes adding further languages later a content task rather than a migration.