We have created a forge ticket about those topic #90430 since months. But there is less response and we are not sure whether it’s unclear how to resolve that?
I hope we become clearness here.
The problem is described in ticket and I’ve made a test environment with ddev which can be easily downloaded and started to understand that problems. They are different database entries in the mm table depending on saving the data in backend.
In general the problem is that:
Having bidirectional relations in translated data
TCA for the relation field has setting l10n_mode=exclude to use the same relations in default language and translated data
just one mm table is defined for both fields in TCA. On local and foreign side
on saving data (with already existing or new added relation) on the local side in default langauge = everything is fine
on saving data (with already existing or new added relation) on the foreign side in default langauge = missing relation in frontend on translated page, and on the page in default language translated values of the relation. I can fix that problem with just saving (without changes) the data of default language on the local side
on saving translated data (with already existing or new added relation) on the local side = missing relation in frontend on translated page, and translated values of the relation on page in default language. I can’t fix that problem with just saving data of default language on the local side. There are two additional entries in the mm table for this relation. They are not removed after saving data.
My question: Why is that behaviour different? How should it be saved in the mm table? In uid_local always the uid from the default language data? Or in uid_foreign the uid from the default language or just the uid of translated data?
At the moment it’s totally unclear what is the correct kind of way to fix it.
I had a similar issue with bidirectional relations (1:n ↔ n:1). In 8 LTS it worked when a translated records relation field was pointing to the record in default language (the “relation” itself had not to be translated). That was working both in extbase as well as backend.
In 10 LTS this was not working any longer. Neither in backend nor in extbase. I had to “translate” the relation itself, the translated records relation field had to point to the translated record instead. This is quite unhandy especially when dealing with lots of records, as every relation has to be “translated”. In addition, l10n_mode=>exclude doesn’t seem to be possible for relations, but it should.
I don’t know (and many others, too) what the currently expected behaviour should look like. As far as i understand, the current situation is the following:
The backend still (10 LTS) expects the relation field to point to the translated record (because when pointing to the L=0 record, i’ve got inconsistences at least in backend IRRE view and localization wizard)
Extbase expects the relation field to point to the translated record, too, like above
l10n_mode=exclude for relation fields is currently not supported for backend
l10n_mode=exclude for relation fields is currently not supported for extbase
In addition, the documentation (extbase + tca) should be updated to better point out the current situation.
Hi
What might be interested for you and helpful for grasping the relations TYPO3 can have is this document. I used it to get my head around what is possible as well as to answer a question - when does TYPO3 store default language record uid and when translated record uid in the relation: https://docs.google.com/document/d/1lfJqotm_omkqIJTgo4xaHteDreBUQ9_Z1_9T6nomv9c/edit?ts=5f9fdbc7