As of the Tokyo release, a Localization Framework Artifact for Surveys is provided ootb.
Currently the ootb artifact does not support Assessments.
So, I've seen a few posts recently about Surveys, Assessments and Quizzes, with questions ranging from "can they be translated?" to "how can they be translated?" or even "should we create more than one survey?". In this post I'm going to try and demystify them and other languages, here goes...
Can they be translated?
Simply put, yes, yes they can. As some of you are already aware, I posted about this a little while back, however for the sake of consistency with this post the high-level notes are these:
As a recap, UI translations in the platform leverage the following tables:
- [sys_documentation] - field labels
- [sys_choice] - drop down choices
- [sys_ui_message] - scripted messages
- [sys_translated] - translatable strings
- [sys_translated_text] - translated text
If you'd like a far more in-depth overview of how it all works check out our training course on NowLearning here,
With that being said, you'll need to follow the following concepts:
- The name / description of the Assessment / Survey - asmt_metric_type.name > sys_translated_text (the "document" field will be the sys_id of your source Survey)
Like this:
- The name of the Category of questions in the Survey - asmt_metric_category.name > sys_translated_text (the "document" field will be the sys_id of the source Category's sys_id which is related to your Survey)
Like this:
- Per question - asmt_metric.question > sys_translated_text (the "document" field will be the sys_id of the question in your survey)
-
- If you have a Description - asmt_metric.description > sys_translated_text (the "document" field will also be the same sys_id of the source question, make sure you populate the element with the right source field correctly)
Like this:
- Per Choice Choices (if you have any for your questions) - asmt_metric_definition.display > sys_translated_text (the "document" field will be the sys_id of the English source in the asmt_metric_definition table)
Like this:
If you are on Quebec+ and you have the "Localization Framework", it is also absolutely possible to make a custom "artifact" to identify these elements, where you can then request translations from the English source survey. Instructions on how to do that are available on Docs here,
Now we know we can, can we simplify the process?
As I stated in the above paragraph, it is absolutely possible to make a custom Localization Framework Artifact which can do the heavy lifting. Before I show you what that looks like, make sure you read through this post to understand the steps on making a custom Artifact, as it details what you need to do (defining a new Artifact, a Processor Script and the necessary UI action that will allow you to "Request Translations").
Ok, so now to the juicy bit that I'm sure you've all been waiting for, if you are looking to make an Artifact that can identify the elements that make up a Survey / Assessment or Quiz then it would need to be defined on the [asmt_metric_type] table, because this is the top of the pyramid of records that make up an Assessment or Survey (as I detail above), then the script would look a little something like this:
(function(tableName, sysId, language) {
var lfDocumentContentBuilder = new global.LFDocumentContentBuilder("v1", language);
assessmentFinder();
function assessmentFinder() {
// lets get the Assessment Type
var amType = new GlideRecord('asmt_metric_type');
amType.addQuery("sys_id", sysId);
amType.query();
if (amType.next()) {
lfDocumentContentBuilder.processTranslatableFieldsForSingleRecord(amType, 'Assessment', 'Name');
// now we need to trawl through the categories, followed by the metrics (questions) themselves
var amCat = new GlideRecord('asmt_metric_category');
amCat.addQuery('metric_type', amType.sys_id);
amCat.query();
while (amCat.next()) {
lfDocumentContentBuilder.processTranslatableFieldsForSingleRecord(amCat, 'Category', '');
var amMet = new GlideRecord('asmt_metric');
amMet.addQuery('category', amCat.sys_id);
amMet.orderBy('question');
amMet.query();
while (amMet.next()) {
lfDocumentContentBuilder.processTranslatableFieldsForSingleRecord(amMet, amMet.getDisplayValue(), '');
// lets get any choices of this question etc
var amChoice = new GlideRecord('asmt_metric_definition');
amChoice.addQuery('metric', amMet.sys_id);
amChoice.orderBy('value');
amChoice.query();
while(amChoice.next()){
lfDocumentContentBuilder.processTranslatableFieldsForSingleRecord(amChoice, amMet.getDisplayValue(), 'Label');
}
}
}
}
}
return lfDocumentContentBuilder.getFinalJSON();
})(table_name, sysId, language);^ This above example is in the Quebec style (in Rome it would be legacy view),
which is to say in Rome+ you would convert it in a call to a Script Include.
I want to stress that this example is exactly that an example, you may find opportunities to improve upon it, tweak as per your needs etc, this is just intended to give you a starting point.
It also serves as a really good example of why I love our API "GlideRecord". When you've grasped it's power, nearly anything is possible. Maybe in a future post I might explore what an Artifact might look like for a full Service Portal, or a Mobile App? - Let me know down in the comments what you'd like to see.
Back on topic to this Artifact, this is what it should look like in the comparison UI when working:
I'm cheating a little bit, because I'm using my demo data translations, however the takeaway here is that it's showing me that the translations already exist for the target elements thus showing that it's working.
Summary
As a recap, yes Surveys, Assessments, Quizzes etc can be translated, either via traditional methods if you know what type of fields and elements are required and then import the translations to the right translation tables or you can venture out and leverage the Localization Framework to do some of that heavy lifting for you (it's important to highlight that the translations via LF still get populated in the same locations, it's just a UX difference in terms of the how).
So, if you know how to structure a GlideRecord query, and you can see and understand the record relationships of what you want to translate feel free to try out your own Artifacts and see how they can help you achieve your translation goals faster.
As usual if you found this helpful, please like, share and subscribe for more
