Dynamic alternate urls and use with localePath (e.g. for using @nuxt/i18n with a headless CMS)

[codeflorist]

@BobbieGoede

I saw, that you locked issue #2100. Maybe i'm wrong, but setI18nParams seems to only be able to set the translated URLs only for the current route. I assume this enables functionality for switchLocalePath. But what about multilinugal linking to another dynamic page (e.g. via localePath({ name: 'products/red-mug' })).

I feel for complete support of e.g. headless CMSs a function should be provided, that can set all translated paths of all routes at the start of the app (e.g. in app.vue) - to achieve the same funtctionality as described on https://i18n.nuxtjs.org/guide/custom-paths).

I have proposed a solution at #2100 (comment).

[BobbieGoede]

setI18nParams is used to provide translations for the parameters used on the current page at runtime, while customRoutes in combination with either the pages config option or defineI18nRoute compiler macro is used to translate the static routes at build time.

Your proposed solution works the same as the page config option and I'm not sure how it differs from it besides it being located in app.vue. You would still have to rebuild the project for it to have any effect, so fetching it would have to occur before build.

I'm not sure if I understand your use case exactly, the issue I closed related to translating parameters but your examples seem to be about translating routes, not its parameters.

[codeflorist]

Thanks for your suggestions. Your code actually highlights the problem i want to convey.

Let's say i want to link to the red mug from the homepage or a news article or any other page. For this to work for all languages i have to do something like this:

// e.g. /pages/home.vue
<script setup>
   const localePath = useLocalePath()
   const { locale } = useI18n()
</script>
<template>
   <NuxtLink :to="localePath({ name: 'products-slug', params: { slug: locale === 'nl' ? 'rode-mok' :  'red-mug' } })" />
</template>

Not only does this get bonkers once i have e.g. 10 languages and want to use these links all around my app, the translations i set with useSetI18nParams in /pages/products/[slug].vue are also completely for nought.

This conveys the basic problem of useSetI18nParams being only useful for switchLocalePath but NOT for localePath.

---

Now let's assume i already know, that there is only a red mug and a blue mug beforehand.

I would ditch @nuxt/i18n's parameter functionality all along and do it this way:

// e.g. /nuxt.config.ts
...
  i18n: {
    pages: {
     ...
      'products/red-mug': {
        en: '/products/red-mug',
        nl: 'products/rode-mok'
      },
      'products/blue-mug': {
        en: '/products/blue-mug',
        nl: 'products/blauw-mok'
      }
    }
  },
...

Now i can use localePath('products/red-mug) (and of course also switchLocalePath) anywhere in the app to get a multilingual link.

BUT, if the pages and their paths in all their languages reside in some backend like a headless CMS, i cannot put them in nuxt.config.ts. I have to fetch them somewhere at the start of my app (e.g. app.vue) and tell @nuxt/i18n about ALL of them so i can create multilingual links in a usable way.

I have written my own implementation of localePath to mitigate, but i definitely believe this to be a valid usecase for @nuxt/i18n - especially for Headless CMSs, which are gaining a lot of popularity, and for which Nuxt is a great fit.

[BobbieGoede]

Let's say i want to link to the red mug from the homepage or a news article or any other page. For this to work for all languages i have to do something like this: ...

I'm assuming products are fetched from an API, the difficulty of usage depends on the way you store your translations.

For example, with a product stored remotely like so:

{
	id: 123,
	name: {
		en: 'Red mug',
		nl: 'Rode mok',
	},
	slugs: {
		en: 'red-mug',
		nl: 'rode-mok',
	}
}

The localePath with params usage would be like this:

// e.g. /pages/home.vue
<script setup>
   const localePath = useLocalePath()
   const { locale } = useI18n()
   const product = // retrieval here
</script>
<template>
   <NuxtLink :to="localePath({ name: 'products-slug', params: { slug: product.slugs[locale] } })" />
</template>

This way you don't have to build routes for all existing products and you wouldn't have to rebuild when a new product is available. Of course there are different methods of storing and retrieving localized data, you can always format your data to use it in a similar way.

[codeflorist]

Thanks again for your suggestions.

Now, translating this solution to my actual usecase - Nuxt using a headless CMS, where i only have a single [...slug].vue inside my pages folder and all paths are fully dynamic, i assume this would be the solution:

// e.g. /components/PageHeader.vue
<script setup>
   const localePath = useLocalePath()
   const { locale } = useI18n()
   const aboutPage = //retrieval here
</script>
<template>
   <NuxtLink :to="localePath({ name: 'slug', params: { slug: aboutPage.slugs[locale] } })" />
</template>

Well in this case, @nuxt/i18n is no help at all, since i can simply do:

// e.g. /components/PageHeader.vue
<script setup>
   const localePath = useLocalePath()
   const { locale } = useI18n()
   const aboutPage = //retrieval here
</script>
<template>
   <NuxtLink :to="aboutPage.slugs[locale]" />
</template>

Or even simpler what i am essentially doing now :

// e.g. /components/PageHeader.vue
<script setup>
   const localePath = useMyOwnImplementationOfLocalePath()
</script>
<template>
   <NuxtLink :to="localePath(aboutPage)" />
</template>

If you still see no usecase for implementing a feature to dynamically give @nuxt/i18n a list of routes and their translations, i doubt i can shift your mind.

Maybe further demand or a solution will arise in the future.

But anyway thanks for your insights and suggestions.

[notflip]

I'm in the exact same situation, slugs not known beforehand, using a Headless CMS system, I decided that it couldn't be done with localePath() but I'm going to try the suggestions above!

@codeflorist What if you want to build a Header.vue file with all the links, that means we need to run a query inside Header.vue to get all the pages and their translated slugs from our CMS, right?

[codeflorist]

@notflip

i think anyone wanting to implement Nuxt with a headless CMS will stumble upon this problem sooner or later. unfortunately, as you can see above, i haven't been able to convince the devs it is a valid usecase to tackle with @nuxt/i18n.

this means, that you will have to ditch @nuxt/i18n's route management completely - essentially using it just for string-translation -
and create your own multilingial route-management with your own localePath and switchLocalePath implementations.

here is the one i'm using with Storyblok CMS:
https://gist.github.com/codeflorist/506f7cd08cd0d733a616d996c56b17b1

you load it in app.vue by calling await useStoryRoutes().fetch().

this way you will have a complete index of all CMS routes available anywhere in your app.

using this you will just have to use localePath of that custom composable in your Header.vue (and everywhere else).

[svenvreenen]

So my basic solution to this is that inside your translation files you add the param for the API so for example

const data = await useFetch=`https://myapi.com/endpoint${t{apilocale}}`

and then. in your translation locale files you can add something like en-GB 'apiLocale' = '&locale=en' to have these queries added to your API request.

(sorry if there is a mistake in the syntax, just doing it out of the hand.)

[WaldemarEnns]

Facing the same issue but in my case:

• using SSR
• all locale slugs are available within each [slug].vue page (I return them from the headless CMS in the Blogpost response)

Issue I am facing:

My alternate links are generated for the current slug - but not using the other translated slugs. Of course, because I have no manipulated the logic to use the translated slugs.

I looked at this method: https://i18n.nuxtjs.org/docs/guide/custom-paths#page-component

Which would have been pretty handy in my case, where I could simply do something like:

defineI18nRoute({
  paths: {
    'en-US': `/posts/${data?.value?.data?.attributes?.localeSlugs.en}`,
    'es-ES': `/posts/${data?.value?.data?.attributes?.localeSlugs.es}`,
    'de-DE': `/posts/${data?.value?.data?.attributes?.localeSlugs.de}`,
  }
})

But it doesn't work for me. The generated i18n alternate links are still only using the de slug (or whatever current locale is selected).

For now I am thinking about just ignoring the alternate & canonical links for my blog-pages but that is not the best solution, if I want to optimize my SEO ranking for my blog.

[svenvreenen]

Ah i see what you mean. i actually faced a similiar issue and decided to just take out the language switcher on my dynamic pages since i couldnt figure out as well. But that said i do think it is a Strapi problem since it is creating a different ID per entry of translations. Thats why I moved recently to Directus.

[BobbieGoede]

For dynamic parameters you shouldn't use defineI18nRoute as this is a compiler macro used only at build time, you would use it to localize the /posts/ segment of your url (/posts/[slug], /posts-in-spanish/[slugs], /posts-in-german/[slugs]).

To translate/localize parameters you should use the useSetI18nParams composable documented here https://i18n.nuxtjs.org/docs/guide/lang-switcher#dynamic-route-parameters.

I'm working on improving the docs for v9, and it's clear these sections should be moved to the custom paths page. Hope this helps resolve your issue!

[WaldemarEnns]

For dynamic parameters you shouldn't use defineI18nRoute as this is a compiler macro used only at build time, you would use it to localize the /posts/ segment of your url (/posts/[slug], /posts-in-spanish/[slugs], /posts-in-german/[slugs]).

To translate/localize parameters you should use the useSetI18nParams composable documented here https://i18n.nuxtjs.org/docs/guide/lang-switcher#dynamic-route-parameters.

I'm working on improving the docs for v9, and it's clear these sections should be moved to the custom paths page. Hope this helps resolve your issue!

That was exactly what I needed and immediately fixed my issue! Thanks a lot! ❤️

[WaldemarEnns]

@codeflorist @svenvreenen maybe that'll help you guys as well 🚀

[codeflorist]

@WaldemarEnns useSetI18nParams only solves the problem for using switchLocalePath but NOT for localePath, when you want to create language-agnostic links to OTHER than the current page. It is also only viable, if one has all language-slugs available within [slug].vue.

In my usecase i get all slugs per language per page using a separate backend-call and functionality at the start of the app. So ideally i'd have a variant of useSetI18nParams, that allows setting localized slugs for ALL pages at once at the start of the app, and not just the current page.