FINALLY! A simple and flexible way to get translations for your notifications, without building notifications for each language.
STATIC Translation allows you to make "Translation" records on a related list to Notifications which map to languages.
DYNAMIC Translations allow you to use your pre-existing Dynamic Translation services to translate emails on the fly.
Great overview, but I think you missed a trick, why not Klingon? 🙂
One thing to add though, in the Notification record, the UI action "Request Translation" leads into the "Localization Framework" which runs a specified "Artifact". So LF would need to be installed and an Artifact setting would need to be set-up as well,
By all means give me a shout if you'd like to discuss more about it and what's been added
Thank you for the short presentation of this feature.
You may know the answer to this because it seems the "email layout" translation is not working, even though the documentation says the layout field (not advanced layout) on the email layout is supported.
I configured the email layout with a simple call to the ${notification:body} and a line of text. Then I translated it to Spanish like the screen below shows. When the Spanish notification is triggered, it shows Spanish from the notification and template but not from the Spanish layout... and shows the information from the English layout.
This is easily reproducible in an OOB instance. Have you run into this issue?
So (currently) I'm afraid it won't call a different layout (e.g. via a mail script), as this feature is just to translate the text in the singularly defined email notification (e.g. the English template to language X). That's a long way of saying you are correct in your observation of it showing a translated version of the English template,
You could in theory edit the translated template of that notification, which should be exposed in a related list when you are viewing the email notification record, which would then be used when it's triggered to be sent.
If however you want to go down the much more advanced route of considerations for Notification per country, check out my blog post here that discusses those types of designs. Just be warned it gets very complex very quickly,
Thank you for your response but I am not quite following you.
The SN documentation clearly saying the Notification Translation feature supports the layout field of the "email layout" record. The "email layout" record has a translation related list and I properly filled it in but the tool is not processing it. It looks like a bug to me.
Ok, so in this example I have my English source email notification (it happens to be the ootb Incident created one):
When you use the Localization Framework to "Request Translations" of it, it will generate a task, you can then either manually or MT translate this English notification and once the task is complete it will generate a record of the template translated (in a new table - viewable in a related list):
These "Translated Notifications" can be tweaked, edited etc but are essentially just generated when the originating notification (in this example the English one) has been translated.
The sequence of use goes a bit like this:
Non-English user has a condition where email is triggered
a Non-English notification has been previously translated and a "Translated Notification" in the Language of the intended recipient's "preference" exists
That email in that Language is then triggered to be sent (not the English - imagine it like an interception)
If the notification had the "Enable Dynamic Translation" tickbox set to true, and your instance was using a CloudMT provider via "Dynamic Translation", then in that case it would use DT if a Translated Notification didn't already exist in the recipients language.
I have a section on it in our "In-Platform Language Support Guide" post, and if you'd like to discuss further I'm of course more than happy to organise a call,
I do understand all that and how it works, which is much better than what it used to be.
My point is that (and using your example) when the Italian translation is sent to a user with Italian as their selected language, whatever is on the email layout for that notification won't be in Italian... no matter if you have an Italian translation of that layout.
In your example I can only see the notification has a template called "email notification template", which most likely has an "email layout". Please test this in your instance and you will see what happens.
Other people is experiencing this as well, click here.
Ah, I think I know what you mean now. In my instance my demo Layout record looks like this:
If I have a data call via ${notification:something} either in the layout, the template or the notification itself (e.g. calling a field from a record) then this wouldn't be processed for translation as that specific string isn't part of the notification, it would be a data lookup.
However, if you are using Dynamic Translation via a CloudMT provider, then because the whole rendered English email is sent ad-hoc for translation, then any and all text will be translated.
If you look at the below example:
It is one of my email templates translated into Italian via a task, and you can see "View Request" is not translated. This is because in this example it is an object call rather than a specified string in the notification. You can also see that the value of the short_description field is not translated as it shows the original "test Italian incident" in English.
However, if I have enabled DT for this notification and not pre-translated the notification or it's template into a specified language, then all of it will be translated such as in this example in Japanese:
So, this is something we're very much aware of and something we're discussing for a future release. Currently it all comes down to the requirements and design of your specific notifications and factoring in what is possible today.
Like you said, it's better than before and we have lots of ideas where we want to take it further, we just have to be mindful that one size won't necessarily fit all,
Thank you for the explanation. It makes sense now and I agree with you that is better to have something now and improve over time. Couldn’t you use gs.getMessage in the corresponding email script to get the “view request” proper translation?
@Sebas Di Loreto, that's the challenge gs.getMessage() is not evaluated as the email itself is generated as it's processed by "system", so if following my long post about various email designs, leveraging a mail_script is technically possible but it is adding quite a bit of complexity,
