You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 4, 2018. It is now read-only.
Reproduced in TYPO3 v8 with EXT:fluidcontent v5.2.0.
The test setup is as follows with a partially translated page:
With this setup, clicking the "Translate" button to localize the "Form" content element fails. What happens is that the translation wizards pops up but never ends at the last step (actually creating translation record).
The final Ajax request throws a HTTP 500. I traced it back to method \TYPO3\CMS\Backend\Controller\Page\LocalizationController::localizeRecords() which gets following parameters:
What is missing is the list of CE's UIDs to be translated. There are none since the item to be translated is within a container and this fails with a 500 (which is semantically wrong but something to fix in TYPO3 Core).
If there is no partial translation, then everything is properly translated (including CEs within containers).
Furthermore (possibly would need another ticket), I found this nearly-perfect workaround:
Edit content element in default language and move it to some zone, outside of a fluidcontent container
Translate the CE
Move back the CE (default language) to the container via drag and drop
The translation is not moved as well but still visible in "Content Area" (this was not the case with a previous version of this extension and is thus fixed)
Moving the translation via drag and drop does not "refresh" the container, it needs a manual reload to show up but actually succeeded.
The text was updated successfully, but these errors were encountered:
I can confirm this behaviour. This is a severe issue which should be fixed "asap". In former versions it was possible to synchronize child elements with default language within the container-element (a good work-around for this problem). This feature is gone for now (TYPO3 7.6.22, fluidcontent 5.2.0), so there's no other option than deleting the whole translated container-element including its children and translating it again :(
The "workaround" you describe does not work either with current versions of TYPO3 7.6 an fluidcontent. Indeed the child element can be localized outside of the container. But after dragging it back into the container-element (default language) this is only applied to the default language. In the foreign languages the child element simply "disappears" and does not have a proper relation to its parent-element...
I have the same problem in a project. Any idea, how to fix the issue? Recreating the content containers seems no option for me, since an editor has to do this every time new content is added to a content container in the main language.
Reproduced in TYPO3 v8 with EXT:fluidcontent v5.2.0.
The test setup is as follows with a partially translated page:
With this setup, clicking the "Translate" button to localize the "Form" content element fails. What happens is that the translation wizards pops up but never ends at the last step (actually creating translation record).
The final Ajax request throws a HTTP 500. I traced it back to method
\TYPO3\CMS\Backend\Controller\Page\LocalizationController::localizeRecords()
which gets following parameters:What is missing is the list of CE's UIDs to be translated. There are none since the item to be translated is within a container and this fails with a 500 (which is semantically wrong but something to fix in TYPO3 Core).
If there is no partial translation, then everything is properly translated (including CEs within containers).
Furthermore (possibly would need another ticket), I found this nearly-perfect workaround:
The text was updated successfully, but these errors were encountered: