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 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 either done via the environment variables: studio.workflow.translation.extendedWorkflow and/or studio.workflow.translation.extendedWorkflow or at runtime via a setting with name WorkflowValidation document at the path /Settings/Options/Settings/, that has the following integer properties at the following property path set: settings.limits.translation.maxDepthToCompleteChangeSet and/or settings.limits.translation.limitForDependentContentItems. 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 WorkflowValidator, you may extend the class LocalizationWorkflowValidator which automatically creates issues with the category localization. Furthermore, all predefined WorkflowValidators for translation, except the ContentStateValidator, produce only issues for the category localization.