[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: |
|
||||||||
| 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. |