I’m trying to setup a content preview link (in the Contentful editor) for a model that is localized. The preview urls should point to different subdomains, so for each language will need separate content previews. The slug of the model is localized and in order to get the correct slug, I need to get hold of the field with a specified locale.
I can’t seem to find any information in the docs of how to retrieve a specific version with the {string variables syntax}.
Anyone that can point me in the right direction of how to get hold of localized value from a field? {entry.fields.slug} returns the default language, in my case en-US as expected. But how do I retrieve the Swedish locale of the slug, my first guess would be something like: {entry.fields.slug[sv-SE]}, but no luck.
However, to work with Content Preview/Gatsby Preview, it seems necessary to write out the complete slug together with localization for each page. e.g. I have to manually maintain a slug content type that contains entries such as:
I ended up also with a custom extension, mostly because I have localization and further rules so the slugs applied during the builds by gatsby (e.g. /en/products/category/title). Such rules for now reside in the ui extension and it looks something like:
I plan to build something that can be more configurable, think would be more valuable to have a slug field that can generate the value based on different tokens, e.g.:
However think that is not feasible at the moment, because that would require a configuration for each content model where we set the custom field extension.
Any ideas on how that approach could work and if that makes sense?
Since sometimes it can be very handy to have the full slug (that can be composed by different fields) generated in Contentful decided to build a custom extension for that:
Is there any update on this? I’m having the exact same issue and I can’t imagine Contentful will just ignore this since localization is a pretty big deal.
I also contacted the support about this and they told me the same thing as @jakob_stenqvist
They did say that they are gonna notify the dev team about this issue.
Thank you for this better slugs extension, I was hoping it would solve my issue with the localized slugs, but as you know it only renders the slug for the default locale.
@jakob_stenqvist do you mind explaining your approach to the custom sidebar?
it looks like if you could render a button that watches for changes in the active locale it could work, though you’d still need to pass it the relevant slug information.
@dnortonnot sure what you mean by default locale, the extension will render for different locales if configured properly, you need to set the locale token in the field appearance screen, e.g.:
I meant that when used as a field for the content preview it is rendered with the default locale even if you’re editing a different locale, ie: if editing ja, i see the slug saving properly as ja/slug-path, but opening the entry in content preview it returns en-US/slug path when the pattern is using {entry.fields.betterSlug}. A proposed workaround that support just suggested was per-locale preview routes that can be selected in the editor page, which should achieve what I need for now, but having it be dynamic based on the actively editing locale would be ideal.
