Major Feature #50800
Localization of new child elements in existing grids
This missing feature affects all TYPO3 versions and all gridelements versions.
Let's say we have 2 languages and when we first entered the content for the default language we use "Copy default content elements" to create the correct translated structure in the overlay language.
If you now add a new content element inside this gridelement you can't see the button "Copy default content elements" which makes it quite hard create a translation for this element.
Of course there is a workaround, you could open the new text element and select the overlay language from the languages dropdown:
But if you do this, you get:
You can now drag-drop the element to it's supposed position.
That causes 2 problems:
1. if you have much content on this page and create new elements in the default language
2. if you delete an element in an overlay language
it's nearly impossible to see which elements are not yet translated and creating the translations is very painful.
So I think the "Copy default content elements" is a necessary function to work with translations.
#2 Updated by Jo Hasenau about 5 years ago
- Status changed from Accepted to Under Review
Actually we would just need an icon/button/link for each Grid-Container that makes use of the inlineLocalizeSynchronize methods, that are already creating the links inside a TCEform of a grid parent. The trick would just be to move the links from the TCEform to the page module.
#3 Updated by Jo Hasenau almost 5 years ago
See the image of #53549 as well http://forge.typo3.org/attachments/25477/translated_text-element_in_wrong_column.png
#4 Updated by Jo Hasenau over 4 years ago
- Status changed from Under Review to On Hold
Currently we have at least the option to synchronize translations using the link within the TCEform.
Checkout the current master for testing this workaround.
The plan is to release 3.0 to the TER first and then provide this new feature with GE 3.1.
#5 Updated by Stefan Rotsch about 4 years ago
we also stumbled upon this issue and I've written a short patch to update the container ID when translating an element inside an already translated container. As I didn't check forge before spending some time with that issue (shame on me ;)) I'll push it to Gerrit... feel free to abandon it if you already have a (better) solution in place.
#8 Updated by Stephan Schuler about 4 years ago
Are you sure about that?
The current implementation of \GridElementsTeam\Gridelements\DataHandler\AbstractDataHandler::checkAndUpdateTranslatedChildren only takes care of "$command === 'copy'".
The explained use case isn't "copy" but "localize", so it isn't covered by that method, imho.
There are other ways to create localized copies of records than. Having a "localize this" button inside of the Gridelements page view is pretty nice, but you cannot avoid having people just use either the very first language dropdown in TCEforms  or just hit a language flag in list module. Both should be covered by some mechanism as well.
The given patch does the trick for every situation I tried. So I would vote for re-adding it.
 No need to re-upload the very same file.
I'm talking about this one mentioned in TCEforms of tt_content in the initial comment of this issue.
#9 Updated by Jo Hasenau about 4 years ago
The core function "localize" makes use of "copyRecord" internally, so everything that applies to copies should apply to localization as well.
To me this seems to be plausible, since a translation of a record at first is just a copy of it with some parameters added and/or modified.
#11 Updated by Stephan Schuler about 4 years ago
Well, actually it's the GridElementsTeam\Gridelements\DataHandler\ProcessCmdmap::execute_processCmdmap() which checks for "$command === 'copy'". And since $command is 'localize', the $this->checkAndUpdateTranslatedChildren() method (inherited from AbstractDataHandler) gets never called in that szenario.
But I'm a bit lost in what's the execute_processCmdmap mechanism all about. Checking for "x" in the value for doing one thing, determining $targetPage by checking if $value<0 ... it's really hard for me to understand even the amount of edge cases this function should cover, currently.
Maybe when adjusting this function we should add some comments why ~5 different scenarios are handled inside of this one function and why the they are determined by the way they are determined.
I'm not saying it's wrong, I just want to hint that strpos($value'x') !== FALSE isn't exactly what I would call easy readable.
#12 Updated by Jo Hasenau about 4 years ago
So we could easily implement that for the "localize" command as well within the same hook.
The method checkAndUpdateTranslatedChildren does almost the same as the one proposed in the patch.
But there is the difference, that it will update stuff for each container translation in just one go.
Actually most of the copying is done in a similar way by the core.
A positive value means "the target is the page where we are going to put the copy on"
A negative value means "the target is the record where we are going to put the copy after"
The X ist just used as a separator to determine different columns keeping the same behaviour for pages and records.
And of course there is a difference between Drag & Drop copies and pasting elements via the context menu.
So you can get:
Default Core stuff 123 => page -123 => record Special Gridelements stuff 123x2 => page column 2 -123x2 => record column 2
#13 Updated by Stephan Schuler about 4 years ago
- that tt_content is determined by negative values when $command 'copy'
- but when ($command 'localize') then tt_content come with positive values.
I just didn't want to adjust that hook unless I talked with you about various scenarios in order to not miss or destroy anything.
I didn't know that "x" indicates internal gridelements mechanisms. I thought about "wow, might be some clicks on image buttons where x/y is relative position of the cursor hitting the button" ... that chould have meant the hook is calles in some other places I just don't know about, like IRRE drag/drop or something. But if "x" always means "column for gridelements" that's no problem for me.
#16 Updated by Jo Hasenau almost 4 years ago
Currently you can use 3 ways to translate children:
1. Use the "Copy default content elements" for existing container/child constructs, since it will handle the whole nested structure and translate it.
2. Use the "Localize/Synchronize" button inside the container form to "upgrade" existing translations of containers after adding new elements in the default language.
3. Add children that haven't got a default language parent within any translated container.
The only new feature, which is planned for 3.1, would be to move the "localize/Synchronize" button from the form to the container preview of the page/language module.