Skip to main content
added 170 characters in body
Source Link

Decision to not allow two WF processes comes from inability of CM to run two WF processes. It is also ambiguous how to orchestrate running one process after another since we do not know what need to be run when. If it need to run in same publication.

Original idea was to configure Translation Review process only in target publication.

You don't really need extra layer of blueprint, you can localize schema in target publication and set Translation review process there. And I believe localized schemas still automatically synchronize field changes from parent schemas.

However I can see how it can be annoying to localize all schemas in all target publications especially if you have lots of languages.

We might to consider some improvements in the future. When Translation process set in source schema will apply to targets only.

For now there is nothing in product to help with this.

Except the fact that you can combine "Component review" and "Translation review" processes in to one. In fact Translation review process can be augmented with any other workflow steps. Also it is possible to set "Translation review process" in to "Associated Component Process" (standard WF process) field.

The challenge here is of course that one part of process is executed in source publication and another in target publication. And process need to cater for both and know in which publication it is running.

enter image description here

By setting this kind of combined process in to "Associated Component Process" (standard WF process) field on source schema. You can get both review with one process.

Decision to not allow two WF processes comes from inability of CM to run two WF processes. It is also ambiguous how to orchestrate running one process after another since we do not know what need to be run when. If it need to run in same publication.

Original idea was to configure Translation Review process only in target publication.

You don't really need extra layer of blueprint, you can localize schema in target publication and set Translation review process there. And I believe localized schemas still automatically synchronize field changes from parent schemas.

However I can see how it can be annoying to localize all schemas in all target publications especially if you have lots of languages.

We might to consider some improvements in the future. When Translation process set in source schema will apply to targets only.

For now there is nothing in product to help with this.

Except the fact that you can combine "Component review" and "Translation review" processes in to one. In fact Translation review process can be augmented with any other workflow steps. Also it is possible to set "Translation review process" in to "Associated Component Process" (standard WF process) field.

The challenge here is of course that one part of process is executed in source publication and another in target publication. And process need to cater for both and know in which publication it is running.

enter image description here

Decision to not allow two WF processes comes from inability of CM to run two WF processes. It is also ambiguous how to orchestrate running one process after another since we do not know what need to be run when. If it need to run in same publication.

Original idea was to configure Translation Review process only in target publication.

You don't really need extra layer of blueprint, you can localize schema in target publication and set Translation review process there. And I believe localized schemas still automatically synchronize field changes from parent schemas.

However I can see how it can be annoying to localize all schemas in all target publications especially if you have lots of languages.

We might to consider some improvements in the future. When Translation process set in source schema will apply to targets only.

For now there is nothing in product to help with this.

Except the fact that you can combine "Component review" and "Translation review" processes in to one. In fact Translation review process can be augmented with any other workflow steps. Also it is possible to set "Translation review process" in to "Associated Component Process" (standard WF process) field.

The challenge here is of course that one part of process is executed in source publication and another in target publication. And process need to cater for both and know in which publication it is running.

enter image description here

By setting this kind of combined process in to "Associated Component Process" (standard WF process) field on source schema. You can get both review with one process.

Source Link

Decision to not allow two WF processes comes from inability of CM to run two WF processes. It is also ambiguous how to orchestrate running one process after another since we do not know what need to be run when. If it need to run in same publication.

Original idea was to configure Translation Review process only in target publication.

You don't really need extra layer of blueprint, you can localize schema in target publication and set Translation review process there. And I believe localized schemas still automatically synchronize field changes from parent schemas.

However I can see how it can be annoying to localize all schemas in all target publications especially if you have lots of languages.

We might to consider some improvements in the future. When Translation process set in source schema will apply to targets only.

For now there is nothing in product to help with this.

Except the fact that you can combine "Component review" and "Translation review" processes in to one. In fact Translation review process can be augmented with any other workflow steps. Also it is possible to set "Translation review process" in to "Associated Component Process" (standard WF process) field.

The challenge here is of course that one part of process is executed in source publication and another in target publication. And process need to cater for both and know in which publication it is running.

enter image description here