TYPO3 Core

It gives me a syntax error (the semicolon in typo3conf/ext/wdb_language_hook/Classes/Hooks/Frontend/Page/PageRepository.php line 131).

Ohh I'm sorry, you can just remove the semikolon in that line.

In the attached extension you can find how fake-entries are used very targeted for powermail.
powermail is using it or something similar by itself to produce in frontend forms with the same html-attribute 'name', so there is a reason for it.
concerning powermail the extension is not working like expected but that's another issue.

My point is that fake-entries should be used in very special cases - if at all - and extbase is doing it completely wrong in my opinion.
I never down-voted the patch but think that the whole construction with fake-entries is a real burden for the whole TYPO3 system.

I will have a look at the extension later (just needed to get this done).

What exactly do you mean by fake entries? No entry is being created here. Can you specify what powermail does?

With fake-entries I mean that a value to a row is assigned that isn't like that in the table:

$row[ $GLOBALS['TCA'][$tableName]['ctrl']['languageField'] ] = 0;

This construction makes proper handling by the core much more more difficult as it's intended to circumvent the core-handling, which is in my opinion the wrong way.

The powermail problem is this:

You create a form, including a powermail-page and fields.
In the original language for fields you create markers which are saved in the database.
Translated records never have these marker-fields but take the markers from the original language. I never found out yet how powermail is doing it in detail, but the purpose is to have in Frontend the same markers, no matter about the language. If markers are different (that can happen if the records are wrong handled by a hook, or even in some fall-back situations perhaps) the forms never work. If powermail-forms never work it can be remarked when the form is shown again after sending instead of showing a response-page.

In my extension I called these fields `intrinsicFields` and they could be configured for every extension - but very targeted and not in general.

Concerning powermail these `intrinsicFields` are handled too late by the hook I used, but the extension serves as example how a targeted usage could be realized in general.

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

$row[$GLOBALS['TCA'][$tableName]['ctrl']['languageField']] = 0;

Does not create a fake record. It's actually used to prime the core language overlay because this only works when the main records is passed.
The other option would be to drop the above code block completely and ignore every relation that does not refer to the base record.
I think the idea with the current code might be, that sometimes relations do not refer to the base record (e.g. because there was no foreign_table_where in a select TCA config that makes sure only sys_language_uid = 0 or l10n_parent = null records are selectable).
Dropping this handling would therefor lead to non resolvable relations in this case.

Regarding powermail: Using getRecordOverlay_postProcessshould work because if there is a translation it should be fetched from database and contain the correct sys_language_uid once passed to getRecordOverlay_postProcessshould as far as I understand the code.

Your extension hooks into getRecordOverlay_preProcess where sys_language_uid will always be 0 if the row comes from extbase. But this is the only time getRecordOverlay does something other then just returning the same data or dropping the row completely if there is a mismatch.

Hi All,
Thanks a lot for putting effort in this area!
The language handling topic is complex and its hard to fix stuff without breaking something else. I've put some months of work to improve the situation for v9 and writing tons of tests. I'm very happy to see other people also caring for it.

Before continuing the discussion, please take a moment to read the concept of the new language handling in v9.5, so we're sure we are on the same page:

https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.5/Important-82363-MakeExtBaseTranslationHandlingConsistentWithTyposcript.html

Also a good start is to see how stuff works and what is missing in the tests, please check out functional tests:
extbase/Tests/Functional/Persistence/QueryLocalizedDataTest.php
extbase/Tests/Functional/Persistence/TranslationTest.php

I'm open for scheduling a call to discuss the topic with whoever is interested.

Please also note that depending on the relation type and configuration uid's used in the relation are sometimes default language record uids and sometimes translated record uids (e.g. in inline relations).
See a summary here for details:
https://docs.google.com/document/d/1lfJqotm_omkqIJTgo4xaHteDreBUQ9_Z1_9T6nomv9c/edit#

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

I thought about this a little further.
The problem here is, that there is a relation between a non translated and a translated record. In this case there are actually two relations (one to the original language and one to the translated version). This happened for some reason when we translated sys_categories (relations were also "translated").
So in addition it would probably be a good idea make sure that only relations to the original record or records that have no translation and are of the current languge can be found through a relation - similar to what happens in the repository when initially loading records.

But sure we can schedule a call if that would help to sort this out :) (maybe via Slack?)

I have the same problem,

a record that is not translateable has child-records which are translateable.

If the child-records are listed, for example for a <select> to edit the child-record (think changing a status from 'open' to 'approved') the selected record will be in the default language, the other records will be in the pages' language.

I think this is an object caching effect as the selected child-record has already been fetched in context to loading the main record.

I think the problem lies in TYPO3\CMS\Frontend\Page\PageRepository->getRecordOverlay
where it checks if($sys_language_content > 0) - this should rather be the $this->context->aspect('language','id')>0
because the pages' aspect holds the correct language-uid

I made a proof of concept by adding a hook with the PageRepositoryGetRecordOverlayHookInterface, and I get the correct results after that, as intended..
(the hook exchanges $sys_language_content with the id from the aspect, and switches it back after the operation)

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

Any news on this?

This bug exists in v10 and v11 too.

• Create a page in default language
• Create a category in default language
• Select that category in page's properties
• Translate the page
• Translate the category

Result: The default page record now has one relation to default category and another one to translated category.

Saving the default page record will erase the second (falsy) translation.

Too bad this didn't get a followup/was abandoned ...

If needed, as a workaround maybe consider this extension (thanks to Georg):
https://github.com/georgringer/extbase_with_no_l10n_parent

Benni Mack wrote in #note-23:

I will have a look if the issues related already solve the problem

Can somebody confirm that Georg's extension (or, this patch - for v12+) solves the issue? https://review.typo3.org/c/Packages/TYPO3.CMS/+/82087

@Benni Mack Haven't used/needed it in a while. But from my comment above I remember that the extension solved an error-case in one project for us.