Bug #80141
Updated by Oliver Hader about 7 years ago
Currently the localization behavior does not consider localization chains concerning field values to be synchronized over multiple localization hops that use the relative l10n_state "source".
Imagine the following scenario of content element:
* [uid:10, sys_language_uid:0, l18n_parent:0, l10n_source:0, header:Value]
* [uid:11, sys_language_uid:1, l18n_parent:10, l10n_source:10, header:Value, l10n_state:{header:parent}]
* [uid:12, sys_language_uid:2, l18n_parent:10, l10n_source:11, header:Value, l10n_state:{header:source}]
Now No if the record of the default record (uid:10) will be updated and the header value set to "Modified", only direct dependents would be synchronized. The automated update of the direct-child localization record (uid:11) does not trigger another update for the grand-child localization (uid:12). To achieve this, the data-map processor has been extended to collect new modifications to the data-map caused by synchronization processes - as long as modifications could be determined, another synchronization round is triggered for the modified items. This way the localization chain is completely synchronized if required, depending on the according l10n_state settings.