- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-23-2023 02:22 AM
We have a HR knowledge base setup to cater for employees across multiple geographies each with different language requirements.
We tested on using translation tasks and created multiple child versions of an article and found that the consumption of these articles are very low. We now have real-time language translation turned on so anyone can translate an article to their preferred language in a single click.
Challenge: While articles can be translated in real time, the article remains in source language (English) and it makes search impossible in this scenario.
Would like to know what are some implementation methods/options that we can consider? Thanks a lot in advance!
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-23-2023 05:37 AM
Hello
We had the same type of issue, we want articles to be search friendly in the native language the users wanted. We found that in order to do that, we needed the articles to be published and indexed, just like you did the first time.
Searchability comes more down to how you document the articles and your content standard. We use the KCS article template. In this template, there is an issue field, and a environment field. We renamed the environment to "related to" as it makes more sense to the user. We created a content standard that focus on being very precise on issue descriptions. We tested using an old article, which used to be known as "imoportant information about the new autosave feature in office365". no user have ever search for the phrase, hence no search results and waste of time translating. with a new content standard, we reduced it down the the just need for search and translations friendly language. example on the new article:
Title: Turn off autosave in Office 365
Issue:
-Do not want autosave
-turn off automatic saving
related to:
-Office365
-powerpoint
-excel
Instructions:
whatever answer the user might need to this issue
when we wrote it this way, the translations came out the other end very well, and the issue and title closely matching the user way of describing their needs/issue, it matched what they were searching for. the automatic translations was also matching well in other languages as the descriptions was made in a very simple language using just short issue statements rather then complex language.
we also this stopped spending time on manually doing the translations tasks, we ended up auto-publishing them as the quality was (not perfect) good enough for end-users. we instead branded the translated child articles as "this is a machine translated article, we value feedback should there be major translations errors"

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-23-2023 05:37 AM
Hello
We had the same type of issue, we want articles to be search friendly in the native language the users wanted. We found that in order to do that, we needed the articles to be published and indexed, just like you did the first time.
Searchability comes more down to how you document the articles and your content standard. We use the KCS article template. In this template, there is an issue field, and a environment field. We renamed the environment to "related to" as it makes more sense to the user. We created a content standard that focus on being very precise on issue descriptions. We tested using an old article, which used to be known as "imoportant information about the new autosave feature in office365". no user have ever search for the phrase, hence no search results and waste of time translating. with a new content standard, we reduced it down the the just need for search and translations friendly language. example on the new article:
Title: Turn off autosave in Office 365
Issue:
-Do not want autosave
-turn off automatic saving
related to:
-Office365
-powerpoint
-excel
Instructions:
whatever answer the user might need to this issue
when we wrote it this way, the translations came out the other end very well, and the issue and title closely matching the user way of describing their needs/issue, it matched what they were searching for. the automatic translations was also matching well in other languages as the descriptions was made in a very simple language using just short issue statements rather then complex language.
we also this stopped spending time on manually doing the translations tasks, we ended up auto-publishing them as the quality was (not perfect) good enough for end-users. we instead branded the translated child articles as "this is a machine translated article, we value feedback should there be major translations errors"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-23-2023 09:50 PM
Greatly appreciate the inputs Kristian! Could you help me clarify:
1. This means that for each article identified for translations, the machine translated article is also created
2. It sounds like this process is fully automated with auto publishing - how is the disclaimer automatically added " this is a machine translated article, we value feedback should there be major translations errors"
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-13-2024 07:55 AM
Hi Per, how did you manage to add the disclaimer to the translated articles automatically?
Do you have a set of best practices to optimize article creation for searchability?
Apologies for digging this post up but we are looking into the same topics.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-27-2023 01:05 AM
- yes. we use a KB to identify this. all articles in the end-user KB is auto-translated
- yes, this is added as a ribbon on top of the article. it was available in the old portal, but it has changed in the employee centre. i am no longer on that project, so not sure how/if they branded them after moving to the new portal I am afraid.