Full i18n implementation for voxr.sh with localized slugs and locale-aware SEO

voxr.sh now has a complete internationalization setup across the Next.js app.

This was not a simple string translation pass. The goal was to make English and French work as first-class locales across routing, navigation, metadata, SEO, and the authenticated app experience. That included localized marketing slugs, locale-aware links, server-side message loading, and a routing layer that correctly handles both language detection and Supabase authentication.

The result is a cleaner multilingual architecture that is easier to maintain and much better suited for international SEO.

What was implemented

The i18n infrastructure now includes a dedicated configuration layer, locale-aware navigation helpers, translated UI messages, bidirectional slug mapping for marketing pages, and a proxy-based middleware flow.

The main pieces are:

lib/i18n/config.ts for locale definitions
lib/i18n/navigation.ts for locale-aware Link, useRouter, and usePathname via next-intl
lib/i18n/slugs.ts for bidirectional slug mapping between English and French marketing routes
i18n/request.ts for server-side locale and message loading
messages/en.json and messages/fr.json for UI translations
proxy.ts to compose slug rewriting, locale detection, and Supabase auth handling

This creates a single foundation for multilingual routing instead of scattering locale logic across the app.

A full app restructure under locale routes

To make the architecture consistent, all routes were moved under app/[locale]/.

The root app/layout.tsx was reduced to a minimal shell, and locale-aware layout logic now lives in app/[locale]/layout.tsx. This makes the current locale part of the route structure instead of something inferred late in the rendering process.

All marketing pages were updated to use locale-aware metadata generation, request locale setup, and localized internal links. Workspace and application components were also migrated away from the default Next.js navigation utilities to the locale-aware navigation layer.

This matters because multilingual support becomes much more reliable when routing, rendering, and linking all depend on the same source of truth.

Localized slugs for marketing pages

One of the most important changes was support for translated marketing slugs.

Instead of forcing the same English URL structure in every locale, voxr.sh now supports localized routes such as:

product ↔ produit
features ↔ fonctionnalites

This improves clarity for users and creates a better foundation for multilingual SEO. A French page can now live on a French URL, while still mapping cleanly back to the equivalent English route internally.

That slug mapping is handled in a dedicated bidirectional layer, which keeps the routing logic explicit and maintainable.

Locale-aware SEO implementation

The SEO layer was updated alongside the routing work.

voxr.sh now includes:

hreflang alternates in metadata
a locale-aware sitemap
locale-prefixed robots.txt
localized metadata generation for marketing pages

This is the right direction for a multilingual site because search engines need clear signals about which page belongs to which language and which URL variants are related.

From a discoverability perspective, this also helps keep English and French pages structurally aligned without forcing duplicate URL patterns or muddying intent between locales.

Locale switcher behavior

The locale switcher was built with a DropdownMenu component and a globe icon.

A key implementation detail is that it uses hard navigation with window.location.href instead of client-side router replacement. It also reads window.location.pathname so it works from the actual browser URL rather than an internally rewritten path.

That decision was important because locale changes needed to pass through the proxy layer. A client-side transition could bypass that logic and lead to stale or incorrect locale resolution.

In this case, a full navigation is the more reliable choice.

Bugs fixed during the rollout

This implementation also surfaced several issues that had to be resolved to make the multilingual setup fully reliable.

1. `middleware.ts` vs `proxy.ts` in Next.js 16

The initial setup conflicted with the newer Next.js requirement to use proxy.ts with a named proxy export instead of the previous middleware.ts pattern.

That was updated so the request pipeline matches the framework’s current expectations.

2. Locale switcher not updating content

The locale switcher originally used router.replace(), which triggered client-side navigation and skipped the proxy layer.

As a result, changing the locale did not consistently update content the way it should. This was fixed by switching to window.location.href, which forces a full navigation and ensures the proxy runs.

3. Broken locale switching on translated slugs

The most important bug affected pages with translated French slugs such as:

/fr/produit
/fr/fonctionnalites
/fr/securite
/fr/ressources

The proxy was rewriting those French slugs to their English equivalents and returning early. Because of that early return, intlMiddleware never ran. Without intlMiddleware, next-intl could not detect the locale correctly and defaulted back to English.

The fix was to run intlMiddleware on the rewritten request and then merge its headers and cookies into the rewrite response.

This ensured that rewritten localized routes still preserved the correct locale context.

Pages with identical slugs across locales, such as solutions and guides, were not affected because they did not depend on slug translation.

Why this matters

The value of this work is not only that voxr.sh is now available in English and French.

The bigger improvement is architectural. The app now has:

a consistent locale-aware routing model
translated marketing URLs
centralized navigation helpers
reliable server-side locale loading
multilingual SEO signals built into the page layer
a request pipeline that handles both language resolution and auth concerns together

That makes future content work easier, future page launches safer, and multilingual growth much more practical.

Final result

voxr.sh now has a proper multilingual foundation across content, routing, metadata, and navigation.

English and French are handled as real locales, not as a thin translation layer on top of an English-first app. Marketing pages can use localized slugs, the SEO layer reflects language variants correctly, and the app routing model is aligned with the current Next.js architecture.

This is the kind of work that is easy to underestimate because much of it happens below the UI. But it has a direct impact on usability, maintainability, and long-term discoverability.

For voxr.sh, it is an important step toward a cleaner international product and a stronger multilingual marketing site.

Follow our journey on voxr.sh.