Oliver Hader authored Mar 04, 2017 and Oliver Hader committed Mar 11, 2017

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 elements:
* { uid:10, sys_language_uid:0, l18n_parent:0, l10n_source:0,
    header:Value, l10n_state:null }
* { 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 if the record of the default language (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.

Change-Id: Ic08460f3ed0071f3dca6c6d1666031895bc3d832
Resolves: #80141
Releases: master
Reviewed-on: https://review.typo3.org/51952


Tested-by: TYPO3com <no-reply@typo3.com>
Tested-by: Susanne Moog <susanne.moog@typo3.org>
Reviewed-by: Susanne Moog <susanne.moog@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: Oliver Hader <oliver.hader@typo3.org>