I am trying to implement notifications in multiple languages. Where the receiver (WorkParty) gets email in preferred language.
There are two people involved in correspondence - the sender and the recipient. Therefore, using Field Values to localize the item in the language of the user who is creating the item may not be correct, as the correspondence really needs to be in the language of the person who is receiving it.
In the document here, it says "your application can respect the language preference of a party"
Question: how do I set the preferred language for a workparty so that pega picks up the localized version of corrospondence ?
I can do the whole thing manually (getting the receiver's locale and selecting the localized correspondence). But this is not what I am trying to accomplish.
In Pega, you can localize the entire application using a localized ruleset which holds the labels and paragraphs for every text on the screen. For example: if your application ruleset is MyApp:01-01-01 then you can create a ruleset MyApp_ja:01-01-01 which holds the japanese translation for all labels. And when user's locale is set to ja_JP, it will pick all japanese labels automatically and display this in sections.
I have created a localized version of the correspondence in MyApp_ja:01-01-01 ruleset, and I want Pega PRPC to pick that localized version when I send email using the notification feature in the Assignment Shape ( Pega 7.2 ) or the Utility Shape Send Email.
whenever a task is assigned to a workparty / worklist, the notification is sent, if approver #1 is selecting "Approve" and clicking submit, PRPC should check the locale of Approver #2 and send him localized version of correspondence. Its not practical to ask Approver #1 to:
1. Pick the receiver from dropdown
2. select the localized correspondence
3. and send email.
I have checked OOTB activities which are preparing and sending emails behind the scene, but I didnt find anything which is trying to send localized correspondence. There must be some OOTB funcationality to make it work without writing everything manually, because I can see in the documentation. it says that pega respect the locale of receiving workparty. But there is no mention of how?
Upon approving by approver 1, there must be one routing logic in place which route the assignment to approver 2.
You need to update the logic ( either via an activity or data transform ) to first identify the locale of the approver 2 and then choose the corresponding correspondance rule based on the locale and then send out the same.
rawap, this is exactly what I tried, when I switch my locale to another language, all emails I sent are picked up from that localized ruleset.
For instance, I am a japanese user, completing my task. And the next task is assigned to a user in America, but the user receives email in Japanese :D
You are correct, if I intervene in the email sending activity and update the current user's locale to receiver's locale it is possible. But its a hack, not the solution unfortunately. and most of these rules are final-internal.
When you say intervene in email sending activity, Are you using some OOTB way of sending emails. I was under assumption that you have a requirement where you are calling Utility/Activity to send email.
Could you let me know what is the exact configuration of sending email?
Email sending APIs are not always bounded by operators (Can also take comma separated emails directly and then no locale context), even though in your use case it is work parties.
I am using the Notification section of assignment shape to send notification to assignee whenever the task is assigned.
I agree with you that I can develop this functionality in my application if I want, but its a very basic requirement for any internationalization. and my concern is:
If its mentioned in the Pega Help Document that its possible, it shouldn't require overriding the OOTB activities and hacking the email functionality. There should be a proper document about this functionality. And that's what I am trying to find. No luck so far :(
Thanks for the link. This is already under discussion internally and you have made a valid point. I will keep you posted on the final outcome. Meanwhile i am hoping that you can go ahead with the suggested approach without any issues.