TYPO3 Core

The bug is just visual. When workspace get's published language changes are correct transfered to the live-version. The problem arises in Class "PageLayoutView" in method "getTable_tt_content" when it loops over the language-array "$langListArr" starting at line:507. The content-records are selected of the current loop-language. The subsequent call of "getContentRecordsPerColumn" selects in a first step live-records of current loop-language and does in a second Step a workspace-overlay. But in workspace content-records have to be selected by there overlay-language.

Solution:
1: If backend is in workspace-view select content-records of all languages
2: Then loop over the array $contentRecordsPerColumn and do a workspace-overlay of each record
3: Now compare the overlay-language with the current loop-language
4: If loop-language and overlay-language are different unset the current record in array $contentRecordsPerColumn

I have added a patch file for TYPO3 Version 8.7.9: typo3/sysext/backend/Classes/View/PageLayoutView.php

Just add new patch-file

I did not reproduce, but I assume this issue still exists.

The problem however is a bit bigger and not only related to workspaces: Changing the language (sys_language_uid) of a record is almost always a bad idea: This easily destroys data integrity for the other fields (l10n_parent and l10n_source).

The real solution is to never allow editors (and admins!) to change the assigned language of a record, basically sys_lanugage_uid, l10n_source and l10n_parent should be 'internal' fields that are not exposed to editor interfaces (FormEngine or page module drag-drop). We would have loved to have that already, but it leads to issues with the '-1 all languages' settings, which has to be changed on a conceptual level before.

This is why the issues has not been fixed: We could probably adapt the page module to deal with this scenario more correctly, but in the end it should not be possible to switch a record to a different language, not even for records being edited in workspaces.

For now, we recommend to never expose these fields to editors (via access rights settings), and to not change the values as an admin.

I'll set the issue to 'needs feedback' for now to give you a chance for a response, and hope that we start working on the underlying issue at some point ...

I'll set the issue to rejected for now: This is more about general language handling and workspaces needs to follow when we tackle the problem on language level.