TYPO3 Core

Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919

We recently picked up this issues again after discussing it in the Translation Handling Initiative. The problem seems to be easy, but actually it shows essential flaws we've got in the core regarding the different translation related fields and their actual purpose and the knowledge about those purposes in the developer community.

I will use a comment of the patches already provided - in this case related to Classes/View/BackendLayout/ContentFetcher - to describe the problem a bit more detailed:

    // Remove a possible translation from the untranslated record uids list.
    // If l10n_source is set, remove this value.
    // Else fall back to l18n_parent, but only if the translation source is the default language.

Actually it is the other way around, since l18n_parent has to get the top priority. If there is a record in a language pointing to a translation parent in the default language, this default language record definitely has to be considered as translated to that language and definitely has to be in connected mode.

1. Either you just translated the default language to the target language, then it points to the same parent element as the l18n_parent field would, but regardless of the translation mode. So in connected and free mode the value would be available and obviously point to the correct parent.
2. Or within the translation wizard you fetched the translation content from another language, which had already been translated. In this case there is no way to determine if a record of the default language has been translated by just looking at l10n_source. So the free mode is not easy to fix.

With core versions before 13 there is the field t3_origuid though, which usually holds the parent of a copy action, which always precedes the data map process of fetching and filling in the actual content during a translation process. While this field could provide sufficient information, it often does not, especially when there were workspace actions involved. This is why the field has been removed during the development of version 13.

So the fix for connected mode is straight forward: Make sure the translation parent field gets the top priority over the translation source field throughout the core.

1. Either we provide a new field that gets the parent of a translation even in free mode but does not determine an actual connection.
2. Or we will have to resolve possible connections between a default language record and a translation in a specific language recursively.
3. Or we will have to provide a kind of translation index similar to the reference index that holds information about default language records and available translations. In this case we could even skip the translation parent field and make the table hold the whole set of information including connected or free mode.

IMHO we should go for options 1 or 2 for the time being but aim for option 3 in the long run.

Still we can come up with a quick fix for the connected mode, since this can be done independently from the free mode solution.