The CreatorCon Call for Content is officially open! Get started here.

List filter returns different number of results based on platform language

Max Nowak
Kilo Sage

Hi,

we're currently having a very strange problem: when I'm trying to filter the category of knowledge articles (kb_category), which is a referece field, I get a different number of results depending on the language I selected in my profile settings.

It seems like some categories are not displayed for languages other than english. While writing this, I looked into the sys_translated_text table, and saw that those categories that are not shown in other languages do not have an entry in this table.

For example, if I set my language to english, create a test category called "TESTCAT 5000" and add an article to it, then switch the language to anything else than english, I will not be able to filter for the category by typing "*TESTCAT" in the list filter, or more generally, using the contains filter.

When I switch the language, change the TESTCAT 5000 kb_category record and save it again, an entry in sys_translated_text is created, and I am able to see the test record by filtering for *TESTCAT.

I guess my question is, is there any way to change this behavior so filters work independant of tranlsations? We don't need to translate the category, and really don't want to create an entry in sys_translated_text for all the languages we're supporting, just so that people using that language can correctly filter the list.

Thanks for your ideas and help!

1 ACCEPTED SOLUTION

Alex Coope - SN
ServiceNow Employee
ServiceNow Employee

@Max Nowak,

Your observation is correct, in that in order to show results of a table that has translated values (in your scenario the categories) per language translations do need to reside in the [sys_translated_text] table in order to represent them. The high-level technical reason for this is because it is being driven by the session language and thus if the system is looking for data in a list and that record is missing in that language it doesn't have anything to show.

At a high-level, it should be pretty easy to make the translations for the categories, because in theory you could write a "Localization Artifact" to identify all of them (similar to how I detailed for Surveys and Assessments in my blog here).

I terms of changing this behaviour, no it's not something you can currently do but it is something we've been discussing whilst weighing up the pros and cons of what that would mean from a UX (User Experience) perspective, as it's not ideal to have a "mixed language" experience for end-users,


Many thanks,
Kind regard 

--------------------------------------------------------------------
Director of Globalization Deployment, Internationalization

View solution in original post

5 REPLIES 5

Hitoshi Ozawa
Giga Sage
Giga Sage

Knowledge is language dependent by default. That is, articles written in English would only be searched is user's language is English.

To enable to search all language, refer to the following article and check "Enable multi language search".

https://community.servicenow.com/community?id=community_article&sys_id=98ecc9cbdbbb04185129a851ca961...

Hi!

Thanks for replying, but I don't think this is the issue, at least I tried and it didn't change anything. I am having this problem when viewing the Knowledge -> Articles -> All table (kb_knowledge), not when searching it on a portal, which I think the solution you provided is for.

It's also not like articles in different languages wouldn't show up in general, it's just that when using a filter on the kb_category field of a knowledge article, like "contains", it will not be able to match the category if there doesn't exist an entry in the sys_translated_text table. The articles of that category are present in the table view, you just can't filter for the category.

Let me provide another example. I have created a new knowledge category called "Testcategory" and created an article in that category, called "test article":

find_real_file.png

When looking at the articles table with english set as my platform language, I'm able to use a filter on the category field and see the record:

find_real_file.png

Now we're switching to another language, say german. As you can see, if I sort by updated, the test article record is visible:

find_real_file.png

 

Now, I want to use list filters to filter the category field, but that doesn't work:

find_real_file.png

So just because there is no entry in sys_translated_text for the knowledge category, I am unable to use list filters, which is pretty... surprising.

 

Alex Coope - SN
ServiceNow Employee
ServiceNow Employee

@Max Nowak,

Your observation is correct, in that in order to show results of a table that has translated values (in your scenario the categories) per language translations do need to reside in the [sys_translated_text] table in order to represent them. The high-level technical reason for this is because it is being driven by the session language and thus if the system is looking for data in a list and that record is missing in that language it doesn't have anything to show.

At a high-level, it should be pretty easy to make the translations for the categories, because in theory you could write a "Localization Artifact" to identify all of them (similar to how I detailed for Surveys and Assessments in my blog here).

I terms of changing this behaviour, no it's not something you can currently do but it is something we've been discussing whilst weighing up the pros and cons of what that would mean from a UX (User Experience) perspective, as it's not ideal to have a "mixed language" experience for end-users,


Many thanks,
Kind regard 

--------------------------------------------------------------------
Director of Globalization Deployment, Internationalization

Hey Alex,

Thanks for the information. In my case, I didn't actually need translations, since we are using  products (or rather, product series) as categories, which obviously are the same in all languages.

I just created a scheduled job that executes a script which creates the missing "translations" (aka entries in the sys_translated_text table, but with the same values).