[MGNLCTS-146] Exporting content with nested multifields does not work Created: 20/Jul/21  Updated: 22/Sep/21  Resolved: 23/Jul/21

Status: Closed
Project: Content Translation Support
Component/s: None
Affects Version/s: 2.5.3
Fix Version/s: 2.5.4

Type: Bug Priority: Blocker
Reporter: Leah Staniorski Assignee: Teresa Miyar
Resolution: Fixed Votes: 0
Labels: cs-bk, i18n, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[X]* Steps to reproduce, expected, and actual results filled
[X]* Affected version filled
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Visible to:
Adam Czyszczon, Bartlomiej Mazur, Lukasz Skolarus, Mateusz Czubak

 Description   

Exporting content with complex nested multi-fields does not work



 Comments   
Comment by Riste Drangovski [ 22/Jul/21 ]

Two main issues were detected:

1. ExportVisitor was not iterating properly over nested multifields.
This issue is resolved by reseting path property in the FOR cycle in iteratePath method.

2. Magnolia saves nested NON i18n multifield with language suffix. 

For example:
When we have nested multifields, parent is i18n, child is NOT i18n.
I would expect magnolia to save the content as:
parent[i18n]/parent[index][i18n]/child/child[index]/property
but magnolia saves the content as:
parent[i18n]/parent[index][i18n]/child/child[index][i18n]/property

Although child multifield is NOT i18n magnolia adds i18n suffix to his index nodes.

As far as we can see this is bug in magnolia.

This issue is resolved by adding extra check if some of the parent fields of the multifield is i18n.

Comment by Riste Drangovski [ 22/Jul/21 ]

For translation of nested complex fields (like: multi in multi field, multi in composite field, etc ...) we recommend to set i18n on the properties (not on the parent container field).
This way magnolia will have same node structure for all languages which is not the case if we set i18n on the parent containing field (in this case magnolia will have different node structure for different languages).

If we set i18n on the container complex field, translations should still work properly with one notice: we export content from the default language for the translation files.
In this case if user adds more content (jcr nodes) for the other languages then default language, we'll export on default language content in the translation files. 

Generated at Mon Feb 12 00:33:41 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.