Adding another language to a product sounds straightforward when described in product terms:

“Let’s support Spanish, French, Dutch, and German.”

The engineering version is less tidy. You are not just translating strings. You are choosing a URL model, a canonicalization strategy, a sitemap shape, and a set of routing rules that search engines and users will both live with for years.

For Trek Point, we made a very specific choice:

  • English stays unprefixed
  • non-default locales use /<lang>/...
  • /en/... redirects back to the canonical unprefixed URL

That sounds small. It had consequences everywhere.

Why We Chose Unprefixed English

English was our default market and our canonical product language. We wanted:

  • short URLs for the default experience
  • stable links in docs, support, and social sharing
  • clean canonical tags for the language most users would see first

The alternative would have been a uniform /<locale>/... scheme for every page, including English. That is simpler to reason about in code. It is also noisier in the common case and tends to leak locale decisions into links that should feel permanent.

We decided the cleaner English URL was worth the extra routing logic.

The Hidden Problem: Locale Prefixes Can Swallow Real Routes

Once you add localized path prefixes, your routing layer can get ambiguous fast.

If /<lang> is too permissive, it starts competing with real routes like /contact, /pricing, or any short path segment that happens to look like a locale. Trek Point avoided that by using a custom URL converter that only matches configured non-default locales.

That single piece of routing discipline prevented a class of bugs that would have been painful to diagnose later.

It is a good example of a broader pattern:

i18n is often a routing problem before it becomes a translation problem

Canonicalization Matters More Than Translation Coverage

One of the easiest mistakes in localized sites is creating multiple valid URLs for the same canonical content.

We explicitly redirect /en and /en/... back to their unprefixed versions. That was not just a cosmetic preference. It prevents duplicate URL surfaces for English content, keeps internal linking simpler, and makes canonical signals much more consistent.

A lot of localization work fails not because the copy is wrong, but because the URL story is muddy:

  • multiple paths serve the same page
  • hreflang tags point to inconsistent variants
  • sitemap coverage drifts from actual routing
  • locale selection logic disagrees with canonical link generation

The user does not see any of that directly, but search engines absolutely do.

Hreflang and Sitemap Work Are Not Optional Extras

If you ship localized paths without good hreflang coverage, you are asking crawlers to guess. Sometimes they guess well. Sometimes they do not.

Trek Point’s marketing routes generate locale pairs intentionally, and the sitemap includes localized variants rather than pretending translated pages are a separate afterthought. That may sound like SEO bookkeeping, but it is really part of the product contract.

We are telling crawlers:

  • these pages are variants of the same concept
  • English is the default canonical path
  • localized pages are first-class, not duplicated content accidents

That clarity matters, especially when the product also has dynamic public pages, planner URLs, and multiple subdomains.

Locale Resolution Is a Product Decision

We also had to define precedence:

  • explicit locale in the URL
  • authenticated user preference
  • browser language
  • default fallback

That ordering shapes more than translation. It affects internal links, support expectations, and whether a signed-in user sees the product in the language they chose even when entering from an unlocalized page.

This is one of those places where a web framework can give you the mechanism, but not the policy. The policy is product work.

What This Design Cost Us

I still think the URL model was the right one, but it was not free.

It added:

  • custom route wiring for marketing pages
  • canonical redirect logic
  • locale-aware URL helpers
  • more care around sitemap generation
  • more testing and review burden when adding or moving pages

If the team had been smaller or the SEO surface less important, a uniform locale prefix scheme would have been a perfectly reasonable trade.

What I Still Like About It

Despite the extra code, the result feels right:

  • English links are clean
  • localized marketing pages remain explicit
  • search engines get a stronger canonical story
  • locale handling is centralized instead of spread across templates

That last point is important. Once i18n logic leaks into every feature team’s ad hoc code, the URL model starts to decay.

The Real Lesson

Localization is not a “translation layer.” It is a structural choice about how the public web surface of your product works.

If you care about search traffic, canonical URLs, and multi-locale UX, then routing, redirects, sitemap generation, and URL helpers belong in the architecture discussion from day one.

The strings are the visible part. The SEO tax is everything underneath them.