Hi All,

We need to localize task header fields in a process, but we cannot select localization resource because here we cannot use the tw.resource namespce:
and we cannot define which localization resources to use at process level because there's no option for it:

So, is there any method or trick (maybe a non-published method?) to use localization resource in task header fields, or we have to call a service to collect the list of localized strings and return into process variables, from which we can use them later?

Thx,

------------------------------
Laszlo
------------------------------

Unfortunately this capability still does not exist in BAW (AFAIK). The underlying problem, as it existed back when localization was first added, I think is still there. The issue is that the data above is stored directly in the DB when the task is created. They are stored there as strings. The UI that displays the tasks ( the "Portal" or "Task Manager") receives the raw data from the DB to display. To enable localization this entire system would have to be changed. And remember localization requires the Browser context to know the right one to pick, so how does this behave for something like the JS-API which can be executed by the system?

While making an API for "get me my task list with localization applied" is doable, It would also create a huge problem around "Search" functionality. Since you can search for tasks based on the Subject, if the values in the DB are just tokens to a resource the search is significantly harder.

None of these are problems that cannot be solved, but given it has been this way since tasks were first introduced it doesn't feel like solving the problem is high on the list of priorities. And it does bring up a question of "How far do you drive this?" If there are variables in the process that are strings, should we provide localization for them as well? I'd also like to understand the process where the people executing it are working in multiple languages in the context of a single instance execution where there isn't an agreed upon "default" language. It seems pretty corner case.

------------------------------
Andrew Paier
------------------------------

Hi Andrew,

Thanks for your reply! Well, now I understand how it works.

On the other hand this code works for Narrative, but do not work for Subject:
<#= tw.system.user.attributes.getPropertyValue("Locale") == "de" ? "Deutsch" : "English" #>

It seems that Narrative is ​​evaluated every time Portal displays it, but Subject hold it's first value after the creation of the task or tw.system.user.attributes.getPropertyValue("Locale") returns null or any other non-valid value, because the Subject is always "English" regardless of the locale of the current user.

Finally we decided to use <german name> / <english name> as process name and task subject.

------------------------------
Laszlo
------------------------------

Original Message:
Sent: Fri March 12, 2021 10:38 AM
From: Andrew Paier
Subject: How to localize task header fields?

Unfortunately this capability still does not exist in BAW (AFAIK). The underlying problem, as it existed back when localization was first added, I think is still there. The issue is that the data above is stored directly in the DB when the task is created. They are stored there as strings. The UI that displays the tasks ( the "Portal" or "Task Manager") receives the raw data from the DB to display. To enable localization this entire system would have to be changed. And remember localization requires the Browser context to know the right one to pick, so how does this behave for something like the JS-API which can be executed by the system?

While making an API for "get me my task list with localization applied" is doable, It would also create a huge problem around "Search" functionality. Since you can search for tasks based on the Subject, if the values in the DB are just tokens to a resource the search is significantly harder.

None of these are problems that cannot be solved, but given it has been this way since tasks were first introduced it doesn't feel like solving the problem is high on the list of priorities. And it does bring up a question of "How far do you drive this?" If there are variables in the process that are strings, should we provide localization for them as well? I'd also like to understand the process where the people executing it are working in multiple languages in the context of a single instance execution where there isn't an agreed upon "default" language. It seems pretty corner case.

------------------------------
Andrew Paier
------------------------------

You approach makes sense.  I've found in the past that in most of these scenarios the individual instances do not need to be multi-lingual and when you drilled In you could figure out something like "When X is true I show German, otherwise I show English". We would then create a service flow "Get Subject for Task" that could return the correct subject for a given task and then you can set that. As we mentioned, it is then static which can have follow on effects for Searches etc.

Glad you found something that worked for you.

------------------------------
Andrew Paier
------------------------------

Original Message:
Sent: Fri March 12, 2021 10:55 AM
From: Laszlo Kertesz
Subject: How to localize task header fields?

Hi Andrew,

Thanks for your reply! Well, now I understand how it works.

On the other hand this code works for Narrative, but do not work for Subject:
<#= tw.system.user.attributes.getPropertyValue("Locale") == "de" ? "Deutsch" : "English" #>

It seems that Narrative is ​​evaluated every time Portal displays it, but Subject hold it's first value after the creation of the task or tw.system.user.attributes.getPropertyValue("Locale") returns null or any other non-valid value, because the Subject is always "English" regardless of the locale of the current user.

Finally we decided to use <german name> / <english name> as process name and task subject.

------------------------------
Laszlo
------------------------------


Original Message:
Sent: Fri March 12, 2021 10:38 AM
From: Andrew Paier
Subject: How to localize task header fields?

Unfortunately this capability still does not exist in BAW (AFAIK). The underlying problem, as it existed back when localization was first added, I think is still there. The issue is that the data above is stored directly in the DB when the task is created. They are stored there as strings. The UI that displays the tasks ( the "Portal" or "Task Manager") receives the raw data from the DB to display. To enable localization this entire system would have to be changed. And remember localization requires the Browser context to know the right one to pick, so how does this behave for something like the JS-API which can be executed by the system?

While making an API for "get me my task list with localization applied" is doable, It would also create a huge problem around "Search" functionality. Since you can search for tasks based on the Subject, if the values in the DB are just tokens to a resource the search is significantly harder.

None of these are problems that cannot be solved, but given it has been this way since tasks were first introduced it doesn't feel like solving the problem is high on the list of priorities. And it does bring up a question of "How far do you drive this?" If there are variables in the process that are strings, should we provide localization for them as well? I'd also like to understand the process where the people executing it are working in multiple languages in the context of a single instance execution where there isn't an agreed upon "default" language. It seems pretty corner case.

------------------------------
Andrew Paier