[EXCONTRANS-353] Translation of custom content app is not working Created: 27/Oct/21 Updated: 11/Jan/22 Resolved: 11/Jan/22 |
|
| Status: | Resolved |
| Project: | Content Translation Extended (CTX) |
| Component/s: | None |
| Affects Version/s: | 3.4 |
| Fix Version/s: | 3.4.2 |
| Type: | Bug | Priority: | High |
| Reporter: | Tobias Kerschbaum | Assignee: | Teresa Miyar |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Magnolia 6.2.12 |
||
| Attachments: |
|
| 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 |
ContextI am just testing the Translation Module extended (deeple) with a custom content app.
if (file.isFile() && FilenameUtils.removeExtension(file.getName()).equals(appName)) {
Otherwise, it will not work because the App name will not be inspirations-app.yaml Steps to reproduce
Expected resultsAll Fields should be translated. Actual resultsOnly the Fields Title, Text and searchText are translated WorkaroundDevelopment notesLike mentioned above, the Problem can be debugged at this line. You can see the bundleReader has only 3 updated bundles:
I also produced a Video to show the behavior: |
| Comments |
| Comment by Riste Drangovski [ 02/Nov/21 ] |
|
This issue is happening mainly because of inconsistency in how fields are handled in content apps. When working with complex fields like: switchable, composite and multi how data is saved in the JCR tree structure is defined from three parameters:
These parameters define if data will be saved in the current jcr node or for example child jcr node, name of the child node or name of the property where data will be saved, etc… When we don’t set explicit values for these properties magnolia should load default values. Problem is that default values for the fields defined in the content app are not the same as the fields defined in magnolia dialogs. So for the example inspirations content-app that is attached, this definition: productLines: field: properties: productCards: field: properties: text: rows: 5 i18n: true product:
needs to be changed to: productLines: entryResolution: propertyNameDecorator: info.magnolia.ui.field.NoopNameDecorator field: itemProvider: $type: currentItemProvider properties: productCards: entryResolution: propertyNameDecorator: info.magnolia.ui.field.NoopNameDecorator field: itemProvider: $type: currentItemProvider properties: text: $type: textField rows: 5 i18n: true product: $type: textField There is also need for improving how this values are handled in: info.magnolia.translation.finder.AbstractPropertiesToTranslateFinder#resolvePropertiesToTranslate For example for multifield entryResolution (and automatically propertyNameDecorator) is not handled in any way. Also we need to cover multiple cases for propertyNameDecorator not just PrefixNameDecorator… |
| Comment by Riste Drangovski [ 20/Dec/21 ] |
|
Magnolia does not handle propertyNameDecorator of entryResolution property. |
| Comment by Teresa Miyar [ 21/Dec/21 ] |
|
From PD: We will add some documentation to address this. |