[MGNLCTS-7] support for non-STK dialogs/templates Created: 10/Jan/11  Updated: 21/Jan/11  Resolved: 20/Jan/11

Status: Closed
Project: Content Translation Support
Component/s: None
Affects Version/s: 1.0.1
Fix Version/s: 1.0.2

Type: Improvement Priority: Neutral
Reporter: kees de koning Assignee: Daniel Lipp
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLCTS-9 ExportCommand may not be exporting al... Closed
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)
Date of First Response:

 Description   

Not sure this is a feature request, a bug, or a missing piece of documentation, but when I first tried to export translations, I got an empty sheet. This is most likely because all our templates and dialogs are custom, and the default setting for nodeDataToTranslateFinder is info.magnolia.module.contenttranslationsupport.export.STKDialogBasedNodeDataToTranslateFinder.

By replacing that with its superclass info.magnolia.module.contenttranslationsupport.export.DialogBasedNodeDataToTranslateFinder things started working.



 Comments   
Comment by Philipp Bärfuss [ 11/Jan/11 ]

Hm, this is wierd. The STK specific implementation does only add the additional dialogs like the ones used to edit the main area. Examples for such dialogs are the article header or section header. I cannot see why this was hiding translatable data in your case.

The clue about this "finder" is that it defines which dialogs have to be reflected to find the "i18n" markers. The paragraph's dialog is configured at the paragraph definition. But if one adds edit-bars explicitly in the template script the system has no knowledge that this dialogs are used to edit a certain node (page or paragraph). As long the dialog is defined on the paragraph/template definition level it should just work.

Comment by Daniel Lipp [ 18/Jan/11 ]

Really strange situation: as the STK-implementation calls the method from the super-class the only reason I could think of for the STK implementation not returning dialogNames (where as the super-implementation does) would be an exception. But in that case, you should get an error message and not a file only containing the headers.

I took various approaches but could not yet reproduce the problem.

Comment by Boris Kraft [ 20/Jan/11 ]

If the problem could not be reproduced, the REsolution should not be "fixed" but "not reproducible"

Comment by Boris Kraft [ 20/Jan/11 ]

If I understand your comment correctly, the issue could not be reproduced. Hence "fixed" is the wrong Resolution. Please resolve with "not reproducible". Thanks.

Comment by kees de koning [ 20/Jan/11 ]

Without wanting to interfere with your internal communication, I would like to credit Daniel here: he DID reproduce and fix the issue

"complex problem - easy solution. It was just that our code in STKDialogBasedNodeDataToTranslateFinder was running into a NullpointerException in your case where as the non-stk implementation ran fine.

The reason was that you actually have a STKTemplate with a MainArea that has no MainAreaInfo set which was an unexpected scenario. Is fixed in SNAPSHOT-1.0.2 and will go into Magnolia 4.4.2."

thanks, Kees

Comment by Boris Kraft [ 20/Jan/11 ]

Hey Kees, no problem. So let's rephrase to "please comment to reflect reality"

Your comment is exactly what I would like to see in every issue we close - what was the problem, what was done about it.

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