Internationalization without regrets

The mistakes we still see

A site built in English, translated to two more languages a year later, and "fixed" with route patches forever after. The fingerprints are easy to spot: hardcoded strings, missing translations on rare pages, currencies that never change, and a search engine that cannot find half of the localized content.

Most of these are not translation problems. They are architecture problems. Translation is the easy part — it is the only part most teams plan for, and it is the smallest fraction of the actual work.

The five layers of localization

When we say a site is "localized," what we really mean is that five separate layers have been thought through:

• Strings. The visible text.
• Formats. Dates, numbers, currencies, units, address layouts.
• Content. Different stories, products, examples — sometimes different services entirely — per market.
• URLs and SEO. How the site signals to search engines that the same content exists in multiple languages.
• Operations. Editorial workflow, translation pipelines, fallback policy, deployment.

A site that nails strings and ignores the other four is not localized. It is a translated front page bolted onto a single-locale product.

Translation is the easy part

The hard part is everything around the text. URLs, slugs, dates, currencies, units, paginated lists, search facets, sitemaps, canonical tags, hreflang tags. Every one of them is a decision — and the right decision depends on the locale, not just the language.

A short list of things that are not "just translation":

• A date that reads "12/04/2026" — which day is that in this market?
• A price formatted with the right currency, in the right position, with the right thousands separator.
• A phone number formatted to the local convention.
• A name field that does not assume "first name" and "last name" map to every culture.
• A search index that knows that "färg" and "farg" should both match.
• A sitemap that lists every locale variant of every page.

A team that hits these on day one ships clean. A team that postpones them adds them as patches forever.

URL strategies — pick once, stick with it

Three honest options, each with consequences:

• Subdirectory prefix. /en/about, /lv/about, /ua/about. One domain, one CDN, the simplest analytics. Default for most teams.
• Subdomain. en.site.com, lv.site.com. Useful if regions need different infrastructure or DNS-level routing.
• TLD per country. site.com, site.lv, site.com.ua. Strongest SEO signal per market, hardest to operate.

There is also the question of the default locale. We almost always recommend dropping the prefix for the default locale (/about for English, /lv/about for Latvian). The reasons:

• The default locale carries the most traffic and shortest URLs help with shares and ads.
• Existing inbound links break less when you keep the unprefixed paths as canonical.
• Search engines handle this case well if hreflang is configured correctly.

Pick once. Stick with it. Migrating URL strategies later is the single most expensive form of localization rework.

The content question

Most teams assume the same content gets translated to each locale. Sometimes that is right. More often, it is not.

A few honest cases:

• Different services. The Ukrainian market may want Telegram-first solutions; the Latvian market may want WordPress-heavy ones. Translating the wrong service page is worse than not having one.
• Different testimonials. Local proof outperforms generic proof. Show a Latvian client to a Latvian visitor.
• Different case studies. A B2B audience in one market may relate to a SaaS case; another may not.
• Different press and partnerships. Local credibility signals matter.

If your CMS only models "one piece of content translated three ways," you will hit this wall fast. Plan for the model where some content is shared and some is per-locale. That is a real engineering decision, not a configuration tweak.

hreflang done right

The most-misconfigured tag on the modern web. The rules that hold up:

• Every page in every locale lists every other locale variant.
• The page lists itself as well (self-referential).
• Use x-default for the locale-agnostic fallback (usually English).
• The hreflang values match the URL exactly — language code, country code if used, the works.

A working hreflang setup tells Google which page to show to a Latvian user searching from Riga. A broken one means the wrong language shows up half the time. The audit takes an afternoon and pays for itself the first week.

Format strategy

Each row is a paper cut on its own. Together they tell the customer that the site was not built for them.

What we lock down before shipping

The checklist we use on every multi-locale project:

1. A list of every string in the codebase, in a translation file, with no hardcoded text anywhere in components.
2. A list of every locale-aware format, with the rule that says when each is used.
3. A fallback policy. What happens when a translation is missing — show the default? Show the key? Crash the build? Pick one and document it.
4. A way to add a fourth locale without touching component code. If adding "fr" requires changes in 40 files, the architecture is wrong.
5. A static rendering pipeline that does not penalize the smaller locales with worse performance.
6. hreflang and sitemap generation that survive content changes.
7. A staging environment that can be browsed in any locale by anyone on the team.
8. A translation workflow the editorial team actually uses.

The teams that lock these down on day one ship with three locales. The teams that postpone it ship with one — and never quite catch up.

The editor's view

A localized site is only as good as the workflow that produces the translations. The questions to answer before launch:

• Who writes the source-of-truth string?
• Who translates it, and how do they know what is new?
• How are translations reviewed before they go live?
• What happens when the source string changes after translation?
• How does the editor preview a locale they do not speak?

If the answer to any of these is "we will figure it out," you will. Just not until the third missed deadline.

When not to localize

Some sites should not be localized at all. The pattern:

• A B2B product with a single global market.
• A niche service where the audience speaks one language by selection.
• A pre-product-market-fit team where the budget is better spent on the product.

Localization is leverage. It is also overhead. If the audience does not split cleanly along language lines, the overhead can outweigh the leverage. Pick honestly.

What we actually deliver

When a team commissions a multi-locale build with us, the deliverables include:

• A typed translation pipeline with build-time validation.
• A static export per locale with proper hreflang.
• A CMS model that supports both shared and per-locale content.
• A staging environment with a locale switcher visible to the whole team.
• A documented workflow for adding a new locale.
• A test suite that fails the build on a missing key.

A site built this way scales to four, five, six languages without becoming a maintenance nightmare. A site built without these decisions stalls at two.