Content Blocks Translations
Feature Request Summary:
We should be able to turn on language variants for content blocks.
Description/Use Cases:
Managing multiple content blocks for a concept because we support over 10 languages is not sustainable. The article language variants allow editors to navigate to the article in their preferred language whereas for content blocks we've had to set up a consistent naming structure with language code so everyone is on the same page.
Business impact of limitation or missing feature:
Having a disparate experience for translation is a large downside of content blocks such that I am more hesitant to use blocks on a lot of articles.
If the account has a lot of content blocks compounded by duplication due to language limitations and since you're not able to search content blocks, you'll need to direct people to an article with the block and then have them edit the content block from there and then re-publish the other articles that use that block.
-
Official comment
Thank you all for your feedback, we are recognizing the need for supporting translations in Content Blocks and we'll try to address it in the future. However, before we get there, we need to keep our focus on other important deliveries, some of which should help with problems also mentioned in the initial request:
- searching for content block
- publishing updates for content blocks -
I wholeheartedly agree with this.
We currently support 3 languages (English, Spanish and Portuguese). We find it extremely cumbersome to have to create three content blocks per article and that's only if we have one content block. Sometimes, we can have as many as 4-5 content blocks per one article.
Not only that, we have to update all content blocks in English, then publish and update Spanish then publish and finally Portuguese and publish. A feature that was supposed to save us a lot of time, ends up tripling (at the very least) the amount of time it takes for us to update articles in all languages at the same time. Additionally, training someone to do this, also takes time. If they miss a step, either a content block won't get updated, the article will be out of date, or a language will be out of date.
-
Content Blocks are very useful and I'm just starting to use them.
Our Knowledge Base supports 9 languages, so a big upvote from my part on this topic!
-
I was really excited to learn about Content Blocks until I saw the lengths we'd have to go to to use them. We support over 25 languages and until there is a way for them to more seamlessly support publishing I can't use them. HUGE upvote from me!
-
In theory, content blocks should save us time. However in practice, this feature is increasing effort tremendously when it comes to localization. We support 5 languages and each time a content block flag is used in an article, it needs to be deactivated manually before the article can be sent for translation via the API. Once translations are completed we then need to reactivate the flag manually. Before we started using this feature, we had a seamless translation workflow. Now, it's incredibly time-consuming due to the manual steps. It requires several teams involved. A feature that should save time turns into a nightmare for localization. Can this be fixed at the earliest opportunity?
-
I also agree with this. We have 4 languages in our help center, planning to add more in the future.
We're redesigning our help center, including using content blocks more. The plan was to help save time and ensure consistency across multiple articles.
I am feeling stressed to discover that the experience of other HC teams here is that the content blocks are making localization a nightmare.
A big upvote for this feature.
Please sign in to leave a comment.
6 Comments