[EXCONTRANS-326] Multivalue and Composite fields fail when using different transformers Created: 14/Jan/20  Updated: 05/Dec/23  Resolved: 30/Jan/20

Status: Closed
Project: Content Translation Extended (CTX)
Component/s: None
Affects Version/s: 3.0.1
Fix Version/s: 3.0.2

Type: Bug Priority: Neutral
Reporter: Richard Gange Assignee: Teresa Miyar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by EXCONTRANS-335 Multivalue and Composite fields fail ... Closed
Relates
relates to EXCONTRANS-412 Composite/multiJcrBlocks Fields Fail ... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Feedback from the customer:

We've debugged the procedure and we noticed that when the source document is generated the transatable i18n fields are searched under the submitted node and not under the Multivalue or Composite node (which are under the submitted node) in our case and that's why the trans-unit element tags not exists in the source document.



 Comments   
Comment by Teresa Miyar [ 14/Jan/20 ]

Complex Multivalue translations are not yet implemented in this module nor in the content translation module, this will be treated as a feature request.

Comment by Richard Gange [ 15/Jan/20 ]

Interesting. So you will try and implement this feature? If so, maybe we can share that code with the other module as well so it's supported everywhere.

Comment by Teresa Miyar [ 15/Jan/20 ]

I'm changing again to bug, after some investigation, the code processes composite and multivalue, problem is in the buildTranslationBundle when it checks if the inner field is direct child of parent node (page in this case)

The explanation is that it works for the multivalue and composite default transformers but we could extend it to the most used ones.

Comment by Richard Gange [ 15/Jan/20 ]

Agreed, only the default transformers seem to work. Which ones are most used though? I think it's all or nothing. Or maybe we can start with:

  • info.magnolia.ui.form.field.transformer.multi.DelegatingMultiValueChildNodeWithLocaleTransformer
  • info.magnolia.ui.form.field.transformer.composite.DelegatingCompositeFieldTransformer

There's no "generic" way to handle it? Are we going to have to write a case for each transformer. Cause any time a new one is added or a custom one configured we could end up in the same boat.

Comment by Teresa Miyar [ 15/Jan/20 ]

Problem is the content translation apps are created to translate properties, this multivalue/composite transformers create nodes and that is why they are more complex to handle, maybe an approach could be to provide a new transformer that instead of storing nodes will create properties like multivaluename_compositename_field1.

Comment by Richard Gange [ 25/Mar/20 ]

Confirmed by customer.

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