Localized pathnames on large websites

[jjjuulliiaann]

Hello!

in the docs the recommended approach for localized pathnames is the pathnames object, that needs to exist on build time and is used by the middleware.

export const pathnames = {
  '/about': {
    en: '/about',
    de: '/ueber-uns'
  },
 
  // Dynamic params are supported via square brackets
  '/news/[articleSlug]-[articleId]': {
    en: '/news/[articleSlug]-[articleId]',
    de: '/neuigkeiten/[articleSlug]-[articleId]'
  },
 
  // Static pathnames that overlap with dynamic segments
  // will be prioritized over the dynamic segment
  '/news/just-in': {
    en: '/news/just-in',
    de: '/neuigkeiten/aktuell'
  },
 
  // Also (optional) catch-all segments are supported
  '/categories/[...slug]': {
    en: '/categories/[...slug]',
    de: '/kategorien/[...slug]'
  }
} satisfies Pathnames<typeof locales>;

This is really useful, as the next-intl link component can resolve all provided pathnames, but I was wondering if this approach is also recommended when you have a lot of locales (~40) and hundreds of urls with localized pathnames (with urls that can also be created independently from new builds).

Would you still try to collect all localized pathnames during build and can this have any performance impact? Or would you rather use some dynamic pathnames with the disadvantage that next-intl doesn't know about the localization of all pathnames?

Some feedback on this would be really helpful. Thanks!

[amannn]

Good question! The pathnames object is imported both into the middleware as well as everywhere the navigation APIs are used, therefore the size of of this object can make a difference. The config should be cached indefinitely with your JS assets though.

If you'd like to reduce the footprint of this config, I think there are currently 3 options:

1. As you mention, using more dynamic segments can help to reduce the number of pathnames, so that could be an option.
2. Alternatively, depending on your application, you could also ensure that navigation APIs are only used on the server side exclusively and not in Client Components. In this case, you could consider putting a import 'server-only' in your navigation file to enforce server-only usage.
3. You could offload link resolving to e.g. a backend endpoint and use that for resolving and building links. See the note about using a catch-all segment in the localized pathnames docs. In this case there's more work on your side though and next-intl can help less with routing.

Hope this provides some help!

[jjjuulliiaann]

Thank you! This is already really helpful.