Feature #96893
open
Option to define Translation behavior default value in TCA
0%
Description
Hi,
we have a multilanguage website and some contents only exist in a language that's not the base language (having sys_language_uid > 0).
We have now the case, that the base language version of those contents (sys_language_uid = 0) might be created later and gets manually connected to the original content element via the Transl.Orig option.
The problem arises if we have relations in both content elements that have no l10n relationship. The relations are deleted in the content element having sys_language_uid > 0.
With the radio option: Translation behavior > "Custom value" instead of "Value of default language" this problem could easily be fixed, but I can see no TCA configuration option to define "Custom value" as a default. It always uses "Value of default language", which then can be changed but at this point it is already to late to preserve my relations.
Therefore I would like to suggest to extend the TCA options by the feature, to define which default "Translation behavior" should get.
How to reproduce this problem:
In my example, this problem arises with news using content elements.
The base language is German (ID 0) and the 2nd language is English.
If my english news record contains content elements and is manually connected to a german news parent record having also content elements, my english content elements are set to deleted=1.
If Translation behavior > "Custom value" would be set, this error could be prevented.
Thanks for checking!
Updated by
Updated by Christian Kuhn about 2 years ago
- Status changed from New to Needs Feedback
Hey. Thanks for your report.
You need to be very careful with the "translation original" (l18n_parent / l10n_parent) field. It basically means that you're changing an element from 'copy' mode to 'translated' mode or vice versa when fiddling with it. This can easily lead to data inconsistencies, especially when relations are involved.
The core is basically built around the idea, when using 'translation mode', that there is always a default language element first. A transition from 'copy' to 'translation' for localized elements is pretty much not implemented and leads to side effects like you described above "my relations are gone".
This area is very hard to get right and I don't think this will change soon. I think, we'll rather try to hide / further restrict these elements in the editing views in the future. Since not only admins but also editors can create quite a mess fiddling with "translation original". This is similar for the 'language selector': The interface happily allows to change a content element from language 'one' to language 'two', which then can lead to the situation that there are two 'two' localization of a default language elements. Similar if you change an element form 'language two' to 'default' or '-1' - all these scenarios are not handled well in this system. That's a very long standing issue and we're trying to mitigate / resolve this mid-term since it leads to a ton of refactoring in critical areas.
I'm afraid to say situations like you described are known and take quite a serious amount of time to get right. There won't be easy upcoming bugfixes. We can only try to slowly improve the situation with younger major core versions.
Until then: Be very careful when doing this and avoid editing both sys_language_uid and l10n/l18n_parent fields in elements.