Support configuring locale prefix strategy per route group

[hTaw99]

Use case

I have an application with two different route groups:

• Guest/Public routes (landing pages, marketing pages, etc.)
• Authenticated/Protected routes

For the public routes, I want to expose the locale in the URL, for example:

• /en/about
• /ar/about

using the "no prefix for default locale" strategy.

However, for authenticated routes, I don't want the locale to appear in the URL at all. Instead, the application should resolve the locale from the authenticated user's preference, for example:

• /dashboard
• /settings

without any locale prefix.

Current limitation

As I understand it, the locale prefix strategy is currently configured globally (e.g. always, never, or as-needed).

This means the same strategy is applied to every route, regardless of its purpose.

Current workaround

The approach I'm currently experimenting with is to avoid wrapping the entire application with a single IntlProvider.

Instead:

• The Guest route group is nested under TanStack Router's optional locale route (e.g. /{-$locale}), and this group has its own IntlProvider that resolves the locale from the URL.
• The Protected route group is not nested under the optional locale route. It has its own IntlProvider, which resolves the locale from the authenticated user's preferences (loaded in beforeLoad).

This setup gives each route group its own localization source and achieves the desired behavior, but it feels more like a workaround than a first-class solution.

Proposal

Would it make sense to support configuring the locale prefix strategy per route group (or per route tree)?

Something conceptually like:

• Guest routes → no prefix for default locale
• Protected routes → no prefixes

This would allow applications to have SEO-friendly localized public pages while keeping authenticated areas clean and relying on the user's stored language preference.

I'm curious if there's already a recommended way to achieve this with the current API, or if this use case aligns with the library's design goals.

[aymericzip]

Ooh, that's a super interesting suggestion! But the limitations are:

• The grouping logic would require listing all groups to include in the bundle.
• It would also add extra logic to every request to determine the matching group before defining the prefix.

I'm a bit concerned that this would hurt the ergonomics, so I'll probably pass on this feature for now.

However, the URL rewrite feature already exists and might solve your use case:
https://intlayer.org/doc/concept/custom_url_rewrites