Get resolved "url" in alternate_languages

Developing with Prismic
1

Hello,

I currently have a blog setup with this custom route: path:

"/:lang/magazin/:category/:uid"
(a fetch with 2 levels deep)

and so I am currently fetching all my documents with get Static Paths in such a format: [category]/[uid] that corresponds to what my Router above is resolving.

I am working with multiple languages, and so for each document (:uid) I also need the associated translated category (:category), for the language switcher, unfortunately the only answer I get from the alternate_languages array is something like this

{
    "id": "YOMt4hIAACUAVGuD",
    "uid": "5-questions-to-ask-yourself-before-starting-a-newsletter",
    "type": "magazin_single_post",
    "lang": "de-de"
}

Any tips or ideas?

Best regards

2

Hi David,

I'll be happy to help you with this.

If you look at the language switcher for our Next.js multi lang example, you simply pass the alternate languages through the link resolver which will fall back on the route resolver. This will treat the alternate language doc as normal document and get the resolved URL as normal.

Let me know if this make sense.

Thanks.

1 Like
4

Hi,

Thanks for your answer but I think I wasn't clear enough in my initial post.

So imagine the following:

I have a custom Type called "blog post"
This blog post type has a Document Link (Content Relationship) to a secondary custom type called "blog category" that is going to be used for nesting my blog posts in categories in my urls (so category-uid/blog-post-uid)

At the moment, It seems that there is no clear way to retrieve this relationship for alternative languages, let's say we take the example from above we suppose we fetch the "blog post" custom type document, we will get its UID, but also it's category in the french language so we will get something like this

(i've stripped all unecessary things to make the example clearer)

{
  "doc": {
    "id": "YN8NohIAACIAQjsp",
    "uid": "my-custom-blog-post",
    "url": "/blog/category-of-the-blog/my-custom-blog-post",
    "type": "blog_post",

    "lang": "fr-fr",
    "alternate_languages": [
      {
        "id": "YOXJERIAACQAX9Tv",
        "uid": "the-post-in-de-ch",
        "type": "blog_post",
        "lang": "de-ch"
      }
    ],
    "data": {
        "category": {
            "uid": "category-of-the-blog",
            "type": "blog_category"

        }
    }
  }
}

So in this example we have a blog post with the uid "my-custom-blog-post" that has the Content Relationship "category" to the custom type -> "blog_category"

And so through the help of the Route Resolver (from slicemachine I may have forgotten to mention that) I'm creating a nested route of a form of :lang/blog/:category/:uid which then creates the "url" response in the example above to make routing faster.

But I don't see (an easy) way to do the same thing for alternate languages, as the uid of the translated category will be different (translated) and so it's not possible without refetching each alternative languages document and get its Content Relationship -> Category -> UID

So for the alternate languages document I am expecting something like: /de-ch/blog/category-of-the-blog-in-de-ch/the-post-in-de-ch

Ideally it would be nice the route resolver from slicemachine -> adds the resolved translated URL to the alternate_languages array, unless there is another way to do so.

Let me know if this explanation was clearer :laughing:

5

OK, then it's as I understood and the solution rests the same, the link resolver will fall back on the route resolver if you haven't included this type in the link resolver. It's then smart enough to find that link already built for you.

All you have to do is pass the alternate_languages array to the component I showed you above, then loop through each object and pass the alt lang object...

{
  "id": "YOXJERIAACQAX9Tv",
  "uid": "the-post-in-de-ch",
  "type": "blog_post",
  "lang": "de-ch"
}

... in to the Link Resolver function href={hrefResolver(altLang)} and like I said it will add the correct route with all the correct categories by language etc.

1 Like
6

Works great, thanks !

1 Like
7

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

9

Very similarly to David's problem, we have a blog where each post has a category, and also each post has translations in different languages. The link structure of a post is "language/category/slug-post". The point is that for alternative languages ​​of the same post, the slug-post and the category change. However currently we can only return the alternative languages ​​of slug-posts, but we cannot return the alternative categories. What we need to know is if there is any way to return the alternative categories of a post?

We tried to implement the solution provided by Phil, but the solution using NextLink, at most, only makes us access the alternative language and the alternative slug-post, that is, this solution returns us a link with the following structure: "alternative-language/alternative-slug-post", ignoring completely the category and not getting access to alternative-category. That is, instead of "alternative-language/alternative-slug-post" we need "alternative-language/alternative-category/alternative-slug-post".
Any tips or ideas?

10

I have the same problem that David was facing before, and after reading this topic, I tried to add a prismic-configuration.js file to my project and add the component that Pill showed, but for me prismic is now rejecting all together the category and opening straing the link with the language,
lang/blog_post
How did you guys solve this?

17

Hey @joao2, the solution for your case would require a similar workaround.

We've discussed this same topic on this other thread. Here you can see how David implemented the additional queries to modify the alternate_languages array to construct a new URL:

This is needed because the Route Resolver doesn't automatically return a route for alternate languages and get the resolved routes for each link in a language switcher.

We've opened a request to solve this, and it's already being tracked in the pipeline of the dev team.

18

Thanks @Pau, can you update us once you have this feature implemented?

We are using a workaround to solve this for now.

Have a great week!

19

Of course. Whenever we get to tackle this, we'll give a public announcement to everyone

20

This thread is being monitored as an open ticket in the issue tracker. We will update this post as we get more information. If you have a similar use-case, you can ‘Flag’ this topic to reopen.