
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-16-2017 05:16 AM
Hi,
Working on an instance with Istanbul, Contextual Search used for Incident deflection both in Service Portal for End users and Incident form for Itil users. We don't have a fully translated instance, only partially translated most of the Service Portal content to Norwegian using the Internationalization plugin. ITIL users are set to English to avoid confusion with partial translation in the main interface. System default language is English.
All/most knowledge articles, that is around 500 articles, are in Norwegian, but were created prior to translating, so are set up with language: English.
Now to the issue. In the Service Portal, any user with language:English will get results in the contextual search on record producers where Contextual search has been set up. Users with Norwegian as language will get no results. If I change the language of the article, Norwegian users will find it, but English users will not.
A long term goal will of course be to translate knowledge articles to both languages and relate them, but I don't see that happening this week and the client is dependent on contextual search functioning both for Itil and End users. The Itil users are proficient in both languages so the article text language is unimportant, but they need to be able to see all articles.
Is there a way to get the contextual search to ignore the user and/or knowledge article language setting?
I am not that familiar with contextual search, so if I could locate the search definition from the contextual search functionality to the knowledge base, that could also point me in the right direction.
Solved! Go to Solution.
- Labels:
-
Incident Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-16-2017 07:04 AM
Hi Kristin
You may try the system property named glide.knowman.search.default_language described in this doc article.
If that property does not suit your requirement, here is an idea:
A brief preface first. The field translations are managed in a table called Translated Text [sys_translated_text], the way it works is quite simple: in that table the system saves the given translation (Language [language]) of any given field (Field Name [fieldname]) in a given table (Table Name [tablename]) for the given record (document [documentkey], which value is actually the sys_id of the record). So for a user who uses a specific language (Norwegian in your case) and updates a record (as the kb article editable form) the system saves two new records (for the fields Short Description and Text) in the Translated Text table, and the language of these translations will be set to Norwegian. From the Translated Text table the system can retrieve the Norwegian translations when they are queried by a Norwegian user.
The idea is to store the value of your kb knowledge articles in the Translated Text by setting the language to Norwegian, but then filling the value with english text.
So, what you would need to do (via some script, eg. a Fix Script) is querying all your knowledge articles, and then for each of them store two records (one for short_description and the other for text) in Translated Text [sys_translated_text] where:
tablename = kb_knowledge
fieldname = short_desccription/text
documentkey = the sys_id of the record currently processed
language = norwegian (check the actual field value of it)
value = the english short_description/text value of the record currently processed
This way you will have the knowledge articles shown in english text for Norwegian users.
Note this is a workaround I would suggest you to use just temporarily. Translating the knowledge articles by properly using the Internationalization tools would be the best option. More info at Language internationalization support.
Also please remember to take a data backup and to test your script in a sub-production instance first.
I hope the above helps.
Best Regards,
Loris D'Avanzo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-16-2017 07:04 AM
Hi Kristin
You may try the system property named glide.knowman.search.default_language described in this doc article.
If that property does not suit your requirement, here is an idea:
A brief preface first. The field translations are managed in a table called Translated Text [sys_translated_text], the way it works is quite simple: in that table the system saves the given translation (Language [language]) of any given field (Field Name [fieldname]) in a given table (Table Name [tablename]) for the given record (document [documentkey], which value is actually the sys_id of the record). So for a user who uses a specific language (Norwegian in your case) and updates a record (as the kb article editable form) the system saves two new records (for the fields Short Description and Text) in the Translated Text table, and the language of these translations will be set to Norwegian. From the Translated Text table the system can retrieve the Norwegian translations when they are queried by a Norwegian user.
The idea is to store the value of your kb knowledge articles in the Translated Text by setting the language to Norwegian, but then filling the value with english text.
So, what you would need to do (via some script, eg. a Fix Script) is querying all your knowledge articles, and then for each of them store two records (one for short_description and the other for text) in Translated Text [sys_translated_text] where:
tablename = kb_knowledge
fieldname = short_desccription/text
documentkey = the sys_id of the record currently processed
language = norwegian (check the actual field value of it)
value = the english short_description/text value of the record currently processed
This way you will have the knowledge articles shown in english text for Norwegian users.
Note this is a workaround I would suggest you to use just temporarily. Translating the knowledge articles by properly using the Internationalization tools would be the best option. More info at Language internationalization support.
Also please remember to take a data backup and to test your script in a sub-production instance first.
I hope the above helps.
Best Regards,
Loris D'Avanzo

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-18-2017 12:30 AM
Thank you. I did the sys_property setting for now and we'll see about making translations or "translations" in the future.