Issues with Localizing Slugs for Multi-Language Site

Hello DatoCMS Community,

I am currently working on setting up a multilingual website using the marketing website sample from the DatoCMS marketplace. I have encountered an issue with localizing the slugs for different languages.

Hereā€™s what Iā€™ve set up so far:

  • I have created a page with an English version (/en/about) and a Turkish version (/tr/hakkinda).
  • Each version has its respective slug: ā€œaboutā€ for English and ā€œhakkindaā€ for Turkish.

Issue: When switching the siteā€™s localization from English to Turkish via the top menu, the system does not redirect to the Turkish version of the page. Instead of redirecting to example.com/tr/hakkinda, it tries to load example.com/tr/about, resulting in a 404 error page.

Steps taken:

  1. I have enabled localization for the slugs in the same content model.
  2. The English and Turkish slugs have been entered correctly in their respective fields.

Despite these settings, the two localized slugs do not seem to link properly, causing the incorrect redirection.

Has anyone faced a similar issue or can offer guidance on how to ensure the correct slug is accessed when changing the language?

Any help or pointers would be greatly appreciated!

Thank you!

Hi @SercanKoc,

Welcome to Dato, and thank you for the report!

Hmm, this looks like an oversight (or just a missing feature) in our marketing demo project. It happens for our example too: Home - DatoCMS Demo

Let me take a look for you and see if we can come up with an easy fix. Please give us a bit of time on this.

If you need it more urgently, you can look at some alternative implementations recommended by Vercel: (not endorsing either of these; they are just examples)

Otherwise, let me investigate this for you with our devs and Iā€™ll let you know as soon as I hear back!

Hey @SercanKoc

Weā€™ll work on it and get back to you as soon as this is updated!

Thank you for the feedback :slight_smile:

Thank you guys for the interest. Matter fact Iā€™m actually just a lawyer and have zero coding skills. Just signed up to github to run this project on vercel. Some things are hard to catch for me but your products are so easy to use so I said why not. Decided to give it a try. Still have more questions on the marketing demo :slight_smile:

Iā€™m sure you guys will update this routing but only problem is that Iā€™m not sure if I will be able to adapt your update to my ongoing project. I will get some help itā€™s if needed of course. Just wanted to thank you for the interest :))

Hey @SercanKoc,

Thank you for that background!

While we can try to help you adapt your project once the slugs are added, please be warnedā€¦ it may involve having to change some of your existing schema and/or code. (i.e. it might be a laborious manual process, and you may end up having to manually move things around a bit). We wonā€™t know for sure until Marceloā€™s done with the feature.

Of course we love it when people try our services out and see if itā€™s right for themā€¦ but given what you said, I wanted to give you a bit of warning that weā€™re what the industry calls a ā€œheadlessā€ CMS. Thereā€™s a more detailed explanation in our Academy, but in brief, this means that weā€™re usually best for teams that do have coders, because you usually need them to make any sort of frontend changes, fix bugs, add features, etc.

What we are NOT is a traditional CMS like Wordpress, where you can edit not just the content but also the user-facing website on your own, without coding. For the right teams, this is actually often why they choose us: it allows content editors to focus on content without risk of affecting the live website, and vice versa (devs can focus on the code without worrying about the content as much). The downside is that it will be very difficult to maintain your website over time if you have no coding ability right now (unless you want to learn, of course!).

If becoming an amateur web developer isnā€™t something you particularly want at this point in your life (and I wouldnā€™t blame you!), you might also want to consider more traditional, WYSIWYG (ā€œwhat you see is what you getā€) page builder services instead, like (not affiliated with any of these, not recommending any in particular, theyā€™re just examples):

If you do want to stick with us, we also have many partner agencies you can work with to help you with the coding side of things: DatoCMS Solution Partners

But that really only makes sense, I think, if you specifically want a headless setup, or like our UI more than those WYSIWYG services ā€“ enough to justify the additional costs.

I hope this doesnā€™t sound dismissive? I just wanted to give you that heads-up because I donā€™t want you to end up building a whole website in our UI only to have no way to make a real frontend (public-facing website). The code and content are completely detached in our case, so you have to be able to work with code (or hire someone who can). Otherwise, probably a more traditional WYSIWYG page builder type thing is more suitableā€¦?

Happy to discuss more details if any of that is unclear :slight_smile:

Hey @roger

I appreciate your previous response regarding to my issue. I wanted to follow up as Iā€™m still facing a problem with the language switcher.

Currently, I have localization enabled for slugs, and everything works fine when I manually enter the correct localized URL (e.g., /tr/hakkinda for Turkish). Also, navigating within the localized pages works as expected.

However, the issue arises when I switch the language using the siteā€™s language toggle. Instead of correctly retrieving the localized slug for the selected language, it keeps the slug from the previous language. For example, switching from English (ā€˜/en/aboutā€™) to Turkish results in /tr/about instead of /tr/hakkinda, causing a 404 error.

Since the slug localization itself is working fine, it seems like the issue is with the logic handling the language switch. Do you have any suggestions or workarounds to ensure the language switcher correctly retrieves the appropriate slug for each locale?

Thanks in advance for your help!

Best,
Sercan

Hey Sercan,

Let me look at that starter kit again and see what I can find. Will investigate and report back soon!

Hi @SercanKoc,

I took a look, but sorry, localized slugs just arenā€™t a feature that weā€™ve added to the marketing starter kit yet. It would be nice to add that at some point (it would be a good feature request), but it is quite complex and will require some code changes in that starter kit.

@m.finamor, do you have any thoughts on that?

If itā€™s not currently planned work (and as far as I can tell, it still isnā€™t), @SercanKoc, I think you will have to hire a coder to add it to your particular project :frowning: It is not enough to just change it in the DatoCMS editor, because your frontend code also has to know how to handle internationalized slugs.

This involves a rewrite of the Next.js routing logic inside that starter kit, as well as adding queries on every content type so that the language switcher ā€œknowsā€ which slug to direct to for every other language. Itā€™s quite a bit more complicated than using the same slug across languages (which of course isnā€™t great for SEO and usability, unfortunately).

The starter kit is just a basic demo to show how the CMS can hook up to an example frontendā€¦ unfortunately itā€™s not meant to be a drop-in deployment-ready production website. Most of our customers just use that example to understand how the connections work, but end up writing their own frontend from scratch to suit their particular needs (itā€™s why they chose a headless CMS, usually).

I think for you, for now, unfortunately the situation is still the sameā€¦ either you use the default features of the marketing starter page (if you donā€™t mind its limited features) or you might have to hire someone to customize it to your liking, and add new features like internationalized slugs.

Iā€™m sorry for the bad news!