Important: Translation sync covers child exclude columns
Description
The update path of the translation synchronisation — the case where a
translation already exists — re-submitted the
l10n_ values
of the profile record only. A child record's exclude value changed after the
child's translation existed therefore stayed stale in that translation: a
contract's
valid_, an address type, a profile information year.
The datamap now covers the whole default-language inline child tree: every
child's propagatable exclude values are part of the same single DataHandler
pass, and the core
Data carries them into every translation
of every touched record.
Two things did not change, and are now pinned by tests:
- File references and MM relations added to the default record after its translation exists were always carried over — the core synchronizes all exclude columns of a touched record from its database row, including the relational ones. The previously documented gap was design-inferred and did not exist. The profile image stopped being an exclude column with Breaking: The profile image translates; the same core pass carries it into every translation whose image follows the default language, so the pin of the exclude behaviour moved to a test column of the test suite and the synchronisation itself has no image-specific code.
enablestays on:Logging sys_rows withlog userid=0are the audit trail of what the synchronisation wrote.
Impact
Editing an exclude column of a contract, address, email address, phone number or profile information record of an already-translated profile now reaches the record's translations on the next synchronisation, the same way it always did for the profile's own exclude columns.
Affected Installations
Every installation using the translation synchronisation of this extension —
through the frontend editing of
academic_, through the
academic: command (which dispatches
After since ACE-490), or by dispatching the event
from its own hooks.