TYPO3 Core

yes, the issue exists in TYPO3 CMS 4.5 as well.

It seems still present in 6.2.14 and 7(latest master); I just performed a test with both and I report my findings:

1) I have 2 languages, italian (L=0) and english (L=1)
2) my TS setup:

config.linkVars = L
config.uniqueLinkVars = 1
config.sys_language_overlay = content_fallback
config.language = it
config.locale_all = it_IT
config.htmlTag_langKey = it-IT
config.sys_language_uid = 0

[globalVar = GP:L = 1]
config.language = en
config.locale_all = en_EN
config.htmlTag_langKey = en-EN
config.sys_language_uid = 1

[global]

page=PAGE
page.10 < styles.content.get

page.20=TEXT
page.20.value=SIDE COL
page.20.wrap=<h2>|</h2><hr>
page.30 < styles.content.getLeft

backend_layout {
    colCount = 2
    rowCount = 1
    rows {
        1 {
            columns {
                1 {
                    name = Main content
                    colPos = 0
                }
                2 {
                    name = Side Content
                    colPos = 1
                }
            }
        }
    }
}

Results:
1) in BE, the colPos of the translated CE is still 0 and not 1 (but I don't think it is fully wrong, I mean, colPos is "translatable" as the other fields, and when I create a new translation of a CE, this is hidden by default, so there's time to adjust the colPos to the correct value

2) in FE, the translated element is in fact placed as it were belonging to the side column and not main column....so it is true that styles.content.get and styles.content.getLeft consider only the colPos of the main language, and this could be confusing.

I can confirm that this issue is not solved in 7 LTS.

Dragging content elements into another column will not move their related translations. Issue pops up in several situations. Moving CE between columns in be_layouts. Dragging CEs into gridelements or try the same in fluidcontent elements.

As Jo already mentioned it appears only if the destination is an empty colum. That's causing the javascript setting a page id instead the previous content element id. IDs of content elements will be negative, page IDs positive.

Description in core:
Position to move to: $destPid: >=0 then it points to a page-id on which to insert the record (as the first element). <0 then it points to a uid from its own table after which to insert it

In the ajax request the colPos for the element itself will be set already in the "process_datamap"-function (\TYPO3\CMS\Core\DataHandling\DataHandler).

After that, the function "process_cmdmap" get executed. Since we are moving an element the function "moveRecord" get called. That again will use "moveRecord_raw" to move the record definitely. Now all our translations will be moved as well.

As you can see, the colPos is not part of that process.
So after everything is done in "moveRecord_raw" the function "fixCopyAfterDuplFields" will be executed. This will update the translation with the correct colPos.

Simplified code passage:

<?php

// After another CE:
// $destPid = 3 (correct page id)
// $origDestPid = -45 (previous content element)

// Is first CE:
// $destPid = 3 (correct page id)
// $origDestPid = 3 (no previous element, so page id will be provided)

// Insert as first element on page (where uid = $destPid)
if ($destPid >= 0) {

    ...

    $this->databaseConnection->exec_UPDATEquery($table, 'uid=' . (int)$uid, $updateFields);
    // Check for the localizations of that element
    $this->moveL10nOverlayRecords($table, $uid, $destPid, $destPid);

    ...

    // fixCopyAfterDuplFields
    if ($origDestPid < 0) {
        $this->fixCopyAfterDuplFields($table, $uid, abs($origDestPid), 1);
    }

    ...

} else {

    ...

    $this->databaseConnection->exec_UPDATEquery($table, 'uid=' . (int)$uid, $updateFields);
    // Check for the localizations of that element
    $this->moveL10nOverlayRecords($table, $uid, $destPid, $originalRecordDestinationPid);

    ...

    // fixCopyAfterDuplFields
    if ($origDestPid < 0) {
        $this->fixCopyAfterDuplFields($table, $uid, abs($origDestPid), 1);
    }

    ...
}

As you can see in case of the first element the function "fixCopyAfterDuplFields" never gets executed since the $origDestPid is positive as we don't have a previous element.

Possible solution could be changing the condition to

if($origDestPid === $resolvedPid) {
    $this->fixCopyAfterDuplFields($table, $uid, abs($origDestPid), 1);
}

But, the function "fixCopyAfterDuplFields" is meant to use a previous content element (which is not available if it is the first CE anyway). So this function would need some attention too.

Hopefully there is someone around with a bigger picture of the overall process (for example, why the dragged content element getting the correct colPos already in the "process_datamap" function?)

Ok "fixCopyAfterDuplFields" as it is doesn't work in its current state. This will be used after copying any record. Fields are defined in $GLOBALS['TCA']['my_table']['ctrl']['copyAfterDuplFields'].

So if I would set the uid from the l18n parent as the "previous content element". Usually it overwrites colPos and sys_language_uid.
In our example, the fields will be copied from the l18n parent (instead of a real "previous CE"). ColPos will be correct at this point, but the sys_language_uid is wrong.

Bump: Hopefully there is someone around with a bigger picture of the overall process (for example, why the dragged content element getting the correct colPos already in the "process_datamap" function)?

Confirmed in master (8.5-dev)

also valid in 7.6.13.

Question is how we can solve that ... as BE Layouts get more and more popular and such basic functionality is broken.

The main problem is to reference by the negative PID (which is actually the UID of the element to be inserted after). If this information is not given or cannot be resolved (e.g. there's just one content element), it's not possible to update to positions.

Thus, the only way to solve this, is to get rid of the negative PID reference behavior in this scenario and submit valid valid imperatives (colPos, sorting, etc.).

atleast in the html we have data-colpos set in the html attributes, so this should be solveable ...

This issue still appears in 8.7.0-dev.
Already an idea or intention to fix that?

One of our customers has the same problem in TYPO3 9 and I can reproduce that issue on TYPO3 10.4, too.
It's not a perfect solution, but I have added a solution as option in Extension Settings of jwtools2 to add a hook into DataHandler which will add the missing DB queries to translated records:

https://extensions.typo3.org/extension/jwtools2

Activate option: typo3ApplyFixForMoveTranslatedContentElements

But I don't found a nice and cool solution in JavaScript to move the translated records directly in one move. So currently you have to reload the right frame on your own to see the changed position of the translated records.

If there is someone with more knowledge to Backend JS feel free to adapt the code and write a patch for TYPO3. I have gived up after 4 hours...

Stefan