Bug #63092
closed
Inline/IRRE records: language field of child records is not updated when modifying parent language field - e.g. problematic for sys_file_reference
Added by Andreas Allacher over 9 years ago. Updated almost 3 years ago.
0%
Description
When I have IRRE records and I modify the language field, e.g. to set it from "0" to "-1" the child records are not updated to that language field but are kept at the ones during creation.
Except "-1" that one never seems to be used.
This can be problematic under certain circumstances, e.g. extbase will not deliver the file anymore via the datamapper as the language of the sys_file_reference is not included.
Updated by Andreas Allacher over 9 years ago
This might be related to some others but the others do not exactly describe this behaviour but might be a result of this.
To auto-change this field might only be interesting under certain circumstances, e.g. if hideTable is active and the language field is not visible (hidden palette).
Updated by Andreas Allacher over 9 years ago
It is even worse when creating a new record, e.g. I create a content element and change the language to non default, the sub-records (e.g. case images) will not have the selected language but the default value (if available, otherwise it has the first available value).
Updated by Andreas Allacher over 9 years ago
Also if the parent record is set to all language (-1) it the child record will be set to default language, even if the child record is a new record and the parent record is already existed because the select is like this:
if ($parentRecord[$parentLanguageField] > 0) {
$record[$childLanguageField] = $parentRecord[$parentLanguageField];
}
Updated by Andreas Allacher about 9 years ago
Just wanted to ask if I need to provide additional information or has there already be something done in regards to this?
Updated by Jo Hasenau almost 9 years ago
- Target version set to next-patchlevel
Just came across that issue while looking for a solution of sorting problems in translated records.
IMHO a parent record with a language set to "all" should be allowed to contain elements with all available language settings. So switching the children to "all" as well would be unexpected at least for my personal taste.
In any other case children should of course be switched to the selected language, since otherwise they will just diseappear in BE and/or FE views.
Updated by Andreas Allacher almost 9 years ago
So you mean the possibility to have the container for all languages but the sub elements for certain languages only?
That might already be an issue in how to display it in the page view.
In any case, even if we allow this, the default setting should still be "-1" for child records and it should at least be possible to create those and not set default to 0
Even if someone were to change thme later on.
Also most users don't have access to the language selector for a record directly, so they can not really select the language here at all.
Updated by Mathias Schreiber over 8 years ago
- Target version deleted (
next-patchlevel)
Updated by Jo Hasenau over 8 years ago
- Category set to Localization
Actually this one seems to be the reason why "Translate" does not work in "copy" mode for children of copied records in CMS 7.
As far as I can see the LocalizationController uses "paste" and "update" on the parent record. So actually it does the same as if an editor just changed the language of that parent record manually. So translations of containers currently work for localization of default language records only.
if ($params['action'] === 'localize') {
if ($srcLanguageId === 0) {
$cmd['tt_content'][$currentUid] = [
'localize' => $destLanguageId
];
} else {
$cmd['tt_content'][$currentUid] = [
'copy' => [
'action' => 'paste',
'target' => $pageId,
'update' => [
'sys_language_uid' => $destLanguageId
]
]
];
}
} else {
$cmd['tt_content'][$currentUid] = [
'copy' => [
'action' => 'paste',
'target' => $pageId,
'update' => [
'sys_language_uid' => $destLanguageId,
'l18n_parent' => 0
]
]
];
}
Updated by Andreas Allacher almost 8 years ago
What might also be an issue is if one changes the language field and adds new child records without saving, the new child record most likely will have the old language uid as value.
Updated by Jo Hasenau over 7 years ago
We discussed that during the coding night and came to the conclusion that #75400 should be fixed by pushing a change of sys_language_uid to any connected child element within the process_datamap() method.
This will not just fix the so called "Copy" mode of the translation modal then, but any this issue as well.
As soon as there is sys_language_uid in the field Array directly after the processDatamap_postProcessFieldArray hook during an update of an existing record, this must push the language to the chain of child elements, excet the value is -1, since this might contain any possible language for children.
Updated by Jo Hasenau over 7 years ago
- Status changed from New to Accepted
- Assignee set to Jo Hasenau
- Target version set to next-patchlevel
- TYPO3 Version changed from 6.2 to 7
This won't be fixed for 6.2 though, but at least for 7.6 since it will fix the broken copy mode of the localization modal.
Updated by Andreas Allacher over 7 years ago
In regards to -1, fair enough but it should at least create newly created children with -1
Though if for example one has a content element at the default language with one image and one wants to move it to language uid -1
then one would need to modify BOTH the CE and the file to -1 with your suggestion.
However, by default the file reference doesn't display the sys language uid so that is not possible.
Maybe if child has the same sys language uid as the parent then did previously it should also be moved to all languages (or at least if parent and child are default language)?
If not, maybe as an optional feature?
Updated by Gerrit Code Review over 7 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/49805
Updated by Gerrit Code Review over 7 years ago
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/49805
Updated by Gerrit Code Review over 7 years ago
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/49805
Updated by Gerrit Code Review over 7 years ago
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/49805
Updated by Gerrit Code Review over 7 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/49805
Updated by Reinhard Führicht about 7 years ago
Hi guys!
Is there any news on this issue?
We are currently having severe problems with this bug and it would be really cool to have this fixed soon.
Updated by Anja Leichsenring almost 6 years ago
- Status changed from Under Review to Needs Feedback
the patch is in WIP since a year.
After latest changes to the localisation behaviour, is this issue still relevant?
Updated by Andreas Allacher almost 6 years ago
I am not sure - haven't tested the exact behaviour in some time but I guess some issues still exist - at least some of the related tasks are still open. Though some have been closed.
Updated by Christian Kuhn over 5 years ago
- Status changed from Needs Feedback to Rejected
patch has been abandoned from review queue since nothing happened on it for about 2 years. to continue work on this issue, please open a new one, gather all available information, link this issue and explain use cases and possible solutions again, please.
Updated by Matthias Krappitz almost 3 years ago
The problem is still there in TYPO3 10. So IMHO this definitely still needs fixing.