Studio Developer Manual / Version 2110
Table Of ContentsThis section covers translation-specific workflow customizations for both the server and the client side.
Studio server
The Studio server customizations are mainly related to workflow issue computation.
Calculation of Dependent Content
Dependent content are content items not explicitly chosen for translation, but which are required to keep in-site links consistent. This is the minimal set of dependent content to be added, but an extended set may be desirable.
The easiest example are two new contents A and B where A links to B. If A is transferred to a derived site via translation, a translation of B is required as well, to mirror the relationship from master to derived.
Extension of this set may be desirable for out of date content: Content A is created and links to existing and previously translated content B. As B already exists, it is not necessarily required to be added as dependent content. But the translation of B is out-of-date. Thus, it may be desirable, adding content B nevertheless.
The behavior can be controlled by choosing a strategy for dependent content calculation. This strategy can be chosen via a checkbox that is displayed over the dependent content section.
You can configure a limit for the dependent content, as well as how deep links should be followed (recommended). This can be done in two ways:
With the following environment variables:
studio.workflow.translation.extendedWorkflowstudio.workflow.translation.maxDependentContentIterations
At runtime as integer properties in a
Settingscontent with nameWorkflowValidationin the folder/Settings/Options/Settings/. The integer properties are inside a nested structlimits.translation:maxDepthToCompleteChangeSetlimitForDependentContentItems
If a limit will be reached, the nagbar will display a warning, which states that not all dependent content has been calculated. Per default the limit does not exist.
Compatibility prior to 2007.1
Prior to 2007.1 the dependent content calculation was different. It also contained the content items which are required to keep in-site links consistent but it did not include outdated dependent contents. Instead, it included existing contents which were added as new links to some contents to translate. These additional dependent contents were meant to provide some context to the translators.
If this behavior meets your requirements, you can still switch back to this
behavior. To do so, simply adapt your DefaultStartTranslationWorkflowForm
with hideDependentContentsStrategyChooser set to true.
Localization Issues
The Translation Workflow displays its issues in two possible categories. These are
localization and content. You can create issues with these categories in order to let
your issue show up either as translation or content specific.
If you write a custom translation workflow validator, you may extend the class
LocalizationWorkflowValidator
which automatically creates issues with the category localization.
Furthermore, all predefined workflow validators for translation, except the ContentStateValidator,
produce only issues for the category localization.
Studio client
The TranslationWorkflowPlugin has some additional configuration options compared to the
WorkflowPlugin:
- isSync
Whether the translation workflow is a synchronization workflow (defaults to
false).- downloadXLIFFButtonVisible
Whether the default button to download the XLIFF document should be visible (defaults to
false).- createWorkflowPerTargetSite
Whether a separate translation workflow should be created per target site on workflow start or whether one workflow for all target sites shall be created (defaults to
fakse).- hideDependentContentsStrategyChooser
Whether the dependent content strategy chooser should be visible for the start workflow form (defaults to
true).- allowSelfAssignedPullTranslation
Whether pull translation leads to automatic self-assignment of the first workflow task (defaults to
true).
