Closed
pyStatusWork field value not selected as display value of work status
In order to set the display value for our work status "Open-HyojunHizukeShutoku" we created a field value pyStatusWork with the desired label (see 1.png).
However, on screen it displays the key, and not the translated "To" value from the field value (see 2.png).
Similar to our phenomenon I found the following articles.
https://pdn.pega.com/support-articles/localized-value-pystatuswork-not-picked-during-display
→ https://pdn.pega.com/support-articles/localized-value-pystatuswork-not-picked-during-display
→ https://pdn.pega.com/community/pega-product-support/question/pega-719-localize-values-are-not-reflected
https://pdn.pega.com/sites/pdn.pega.com/files/help_v731/procomhelpmain.htm#tools/localization/ui-localized-properties-ref.htm
But there are some key differences:
・ my own Live UI found that the property pyStatusWork (is on section pyCaseAssets and) uses the control "Formatted text", not "pyWorkAssignmentStatus" as the above articles suggest. "Formatted text" is auto-generated so I can't see its HTML to determine what field value it is attempting to access;
・ I created a field value pyStatusLabel identical to pyStatusWork above as suggested in the first article but it had no effect;
・ I created a field value pyCaption identical to pyStatusWork and it worked: the translate "To" value of the pyCaption was used.
So here are the questions:
1. pyCaption is the most generic field value: surely this is not the recommended way to translate pyStatusWork?
2. Why is the translation in the field value pyStatusWork not used?
3.
Show More
In order to set the display value for our work status "Open-HyojunHizukeShutoku" we created a field value pyStatusWork with the desired label (see 1.png).
However, on screen it displays the key, and not the translated "To" value from the field value (see 2.png).
Similar to our phenomenon I found the following articles.
https://pdn.pega.com/support-articles/localized-value-pystatuswork-not-picked-during-display
→ https://pdn.pega.com/support-articles/localized-value-pystatuswork-not-picked-during-display
→ https://pdn.pega.com/community/pega-product-support/question/pega-719-localize-values-are-not-reflected
https://pdn.pega.com/sites/pdn.pega.com/files/help_v731/procomhelpmain.htm#tools/localization/ui-localized-properties-ref.htm
But there are some key differences:
・ my own Live UI found that the property pyStatusWork (is on section pyCaseAssets and) uses the control "Formatted text", not "pyWorkAssignmentStatus" as the above articles suggest. "Formatted text" is auto-generated so I can't see its HTML to determine what field value it is attempting to access;
・ I created a field value pyStatusLabel identical to pyStatusWork above as suggested in the first article but it had no effect;
・ I created a field value pyCaption identical to pyStatusWork and it worked: the translate "To" value of the pyCaption was used.
So here are the questions:
1. pyCaption is the most generic field value: surely this is not the recommended way to translate pyStatusWork?
2. Why is the translation in the field value pyStatusWork not used?
3. If pyCaption (or pyStatusLabel, or any other field value) is the correct location for the translation, why do we still need a pyStatusWork field value?
Show Less
Posted: 6 years ago
Pegasystems Inc.
US
What version are you on? In a random sampling of a few different systems I did find the status used pyWorkAssignmentStatus, which then later translate to pyStatusLabel.
In either case, if you're finding that in your implementation it is using "Formatted text", then one way to find out how/why it is localizing the way it is, is to view the gen java of the section you are inspecting. (So in your case, it sounds like "pyCaseAssets") Search for instances like "getLocalizedText..", and you will likely find a lookup for pyCaption based on what you have discovered in your sample.
Posted: 6 years ago
Pegasystems Inc.
JP
The current client is on PRPC 7.2.2; the previous one was 7.3 and later 7.3.1, and I observed the same behaviour on all three versions.
On the previous site I thought, from the above links, that the correct workaround was to modify the OOTB sections and change "Formatted text" to "pyWorkAssignmentStatus", but the L2 engineer who handled the SR I raised indicated that this was not correct: the pyWorkAssignmentStatus workaround (=defining pyStatusLabel) was for screens which use pyWorkAssignmentStatus; standard PRPC flow screens do not and we shouldn't have to modify the control type just to get the translation to work. Which raises the question - from which screens are you seeing pyWorkAssignmentStatus? I don't see it in the standard screens which are produced by Case Manager.
In the end, we found that for screens which use "Formatted text", defining pyCaption worked, and the SR sort of just petered out. Now I have a little more time I would like to get to the bottom of this - is pyCaption the correct way to handle this and if so why is it not documented anywhere?
The other question is: if pyStatusLabel is the correct way to translate screens which use "pyWorkAssignmentStatus" and pyCaption is the correct way to translate screens which use "Formatted text", what is the field value pyStatusWork for and what should go in its translate "To" value?
Show More
The current client is on PRPC 7.2.2; the previous one was 7.3 and later 7.3.1, and I observed the same behaviour on all three versions.
On the previous site I thought, from the above links, that the correct workaround was to modify the OOTB sections and change "Formatted text" to "pyWorkAssignmentStatus", but the L2 engineer who handled the SR I raised indicated that this was not correct: the pyWorkAssignmentStatus workaround (=defining pyStatusLabel) was for screens which use pyWorkAssignmentStatus; standard PRPC flow screens do not and we shouldn't have to modify the control type just to get the translation to work. Which raises the question - from which screens are you seeing pyWorkAssignmentStatus? I don't see it in the standard screens which are produced by Case Manager.
In the end, we found that for screens which use "Formatted text", defining pyCaption worked, and the SR sort of just petered out. Now I have a little more time I would like to get to the bottom of this - is pyCaption the correct way to handle this and if so why is it not documented anywhere?
The other question is: if pyStatusLabel is the correct way to translate screens which use "pyWorkAssignmentStatus" and pyCaption is the correct way to translate screens which use "Formatted text", what is the field value pyStatusWork for and what should go in its translate "To" value? Surely pyStatusWork (the property) alone is sufficient, and the pyStatusWork (the field value, and the unused translation it holds) is superfluous, no?
I tried looking at the java for both the control and the section, but the control "Formatted text" (=pxDisplayText) didn't have any reference to pyCaption and the section "pyCaseAssets" had many references and it wasn't clear which one, if any, handled the particular status at question.
Show Less
Posted: 6 years ago
Pegasystems Inc.
JP
Hi Hari, thanks for the response.
After you change the control type to GetLocalizedValue, where do you save the localized value you want the system to pick up? Is it the field value pyStatusWork? If not, do you still need the field value pyStatusWork?
On a different note: ultimately this is also changing the control type in the same way that I changed the control type to pyWorkAssignmentStatus after the hint from the above articles. Having to change an OOTB section on an OOTB flow just to get localization to work is something better avoided if possible (but the above information would also be nice in case it's not).
I should also make a clear distinction between two things.
① Transliteration (I made that word up) is replacing the key of a label (in my case pyStatusWork) with a different text value, irrespective of the locale. I understand this to happen through field values.
② Localization is choosing a different text value from that which would normally be transliterated based on the locale of the user. I understand this to happen through further placing the above field values in language specific rulesets.
My article is about "transliteration", and from my best observation so are the articles which I referenced (even though they say "localization" in their titles). However, technically "transliteration" could be thought of as "localization for the default case, i.e. for locales which don't have a language pack installed"? I don't know if that's what the articles above intended.
To see attachments, please log in.