Full i18n implementation for voxr.sh with localized slugs and locale-aware SEO
A technical update on how voxr.sh now supports English and French with next-intl, translated marketing slugs, locale-aware metadata, and a proxy-based routing setup in Next.js.
Introduction
voxr.sh now has a full internationalization setup across the Next.js app.
This was not a simple translation pass. The objective was to make English and French work as first-class locales across routing, navigation, metadata, SEO, and the authenticated app experience. That meant treating language as part of the application architecture, not as a cosmetic layer added at the end.
The implementation now covers translated UI messages, locale-aware links, localized marketing slugs, server-side locale loading, and a request pipeline that handles both language resolution and Supabase authentication. The result is a multilingual foundation that is cleaner to maintain and significantly better suited for international discoverability.
Engineering perspective
From an engineering point of view, the main challenge was to make localization consistent across the full application stack.
The i18n setup now relies on a dedicated structure instead of spreading locale logic across individual pages. Locale definitions live in lib/i18n/config.ts, locale-aware navigation is handled through lib/i18n/navigation.ts, translated marketing slugs are managed in lib/i18n/slugs.ts, and server-side locale plus message loading is handled in i18n/request.ts. UI translations are stored in messages/en.json and messages/fr.json. On top of that, proxy.ts composes slug rewriting, locale detection, and Supabase authentication handling into a single request flow.
To make the architecture coherent, all routes were moved under app/[locale]/. The root app/layout.tsx was reduced to a minimal shell, while locale-aware layout behavior now lives in app/[locale]/layout.tsx. This makes the active locale part of the route structure itself, which is more reliable than trying to infer it later during rendering. It also keeps routing, rendering, and metadata generation aligned around the same source of truth.
One of the most important implementation details was localized slug support for marketing pages. Instead of reusing English URLs for every locale, voxr.sh now maps equivalent routes explicitly, such as product to produit and features to fonctionnalites. That mapping works in both directions, which keeps route handling explicit and maintainable. It also avoids hiding important URL behavior inside scattered conditionals or page-level exceptions.
The SEO layer was updated alongside the routing model. Marketing pages now generate locale-aware metadata, language alternates, and locale-specific crawl signals. This keeps the multilingual site structurally coherent and reduces ambiguity between language versions. In practice, multilingual SEO only works well when routing and metadata are built together rather than treated as separate concerns.
The locale switcher also required a deliberate technical choice. It uses a hard navigation through window.location.href rather than client-side router replacement. That decision was necessary because locale changes must go through the proxy layer. A client-side transition could bypass part of the request pipeline and produce stale locale resolution, especially on rewritten routes. In this case, full navigation is the more dependable behavior.
This work also surfaced framework-level and routing-specific issues that had to be corrected. The request pipeline was updated to follow the newer Next.js requirement around proxy.ts instead of the older middleware.ts pattern. The locale switcher was fixed after client-side transitions failed to trigger the locale layer correctly. A more subtle bug affected translated French marketing slugs because the rewrite logic returned too early, preventing next-intl from resolving the correct locale. The fix was to run the internationalization middleware on the rewritten request and merge its headers and cookies into the final response. That ensured rewritten localized routes preserved the correct language context.
Taken together, these changes create a more stable multilingual architecture. Routing, localization, metadata, and authentication now work within the same request model, which makes future changes safer and reduces the risk of one layer drifting out of sync with another.
Product perspective
From a product perspective, this work matters because internationalization is not just about translating interface text. It is about making the product usable, understandable, and discoverable for different language audiences without making one of them feel secondary.
Before this kind of implementation, multilingual support often remains partial. A site may display translated copy while still exposing English-first URLs, inconsistent navigation behavior, or incomplete metadata. That creates friction for users and weakens the product’s credibility in non-default markets. A French-speaking visitor should not feel like they are navigating an English product with translated labels on top.
By treating English and French as real locales, voxr.sh becomes more coherent for both audiences. Marketing pages can live on language-appropriate URLs, internal navigation behaves consistently, and the language context is maintained more reliably across the app. That improves clarity for users and reduces the sense of translation being an afterthought.
This also has a direct impact on growth and discoverability. A multilingual product needs language-specific landing pages that search engines can understand clearly and users can trust immediately. Localized slugs and locale-aware metadata make those pages more relevant to the people they are intended to reach. That improves the likelihood that users arrive on the right version of a page and understand its value without friction.
There is also an important operational benefit. A structured i18n foundation makes future content expansion more practical. New marketing pages, documentation, and product surfaces can follow the same multilingual model instead of reintroducing ad hoc rules each time. That reduces launch risk and makes international growth more sustainable.
The broader value is that voxr.sh is now better positioned as an international product rather than a single-language app with added translations. The experience is more consistent, the site structure is more credible, and the product is easier to expand across markets without duplicating effort or compromising clarity.
Conclusion
The internationalization work on voxr.sh was about much more than translating strings.
The app now has a proper multilingual foundation across routing, navigation, metadata, and SEO, with English and French handled as first-class locales. Localized slugs, locale-aware metadata, server-side message loading, and a unified proxy layer make the architecture more reliable and much easier to maintain.
That technical foundation also creates a better product outcome. Users get a more coherent multilingual experience, marketing pages become more discoverable in their intended language, and future international growth becomes easier to support without rebuilding core systems.
For voxr.sh, this is an important step toward a stronger multilingual product and a more credible international web presence.
Follow our journey on voxr.sh.