Bug #21964

New child records created from a translated record have default language

Added by Marcel Greter over 9 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
-
Start date:
2010-01-15
Due date:
% Done:

0%

TYPO3 Version:
4.3
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

You can find an example here: http://www.olly.de/typo3/irre_localization.html @ 2:20

In the example a german hotel record is edited and the editor then creates a new offer. As you can see at 2:25 the new created offer has the language set to default. I myself use a intermediate table and the relation record also is created in default language. If I edit the relation record, the first item is an "invalid value (x)" (as it is looking for the id with default language, but in fact it is pointing to the record in german). If I set the child and relation record to german it is working as expected. IMO, l18n_parent could/should also be set.

Marcel Greter

(issue imported from #M13250)

class.t3lib_tceforms_inline.php.patch View (1.22 KB) Administrator Admin, 2010-01-18 16:34

class.t3lib_tceforms_inline.php.v2.patch View (1.52 KB) Administrator Admin, 2010-04-20 17:09


Related issues

Related to TYPO3 Core - Bug #40656: t3lib_TCEforms_inline->createNewRecord doesn't create localized records Closed 2012-09-05
Duplicates TYPO3 Core - Bug #57063: Parent language is not applied to new child records Closed 2014-03-19
Blocks TYPO3 Core - Bug #48883: Wrong sys_language_uid in sys_file_reference Closed 2013-06-05

History

#1 Updated by Marcel Greter over 9 years ago

Please forget about l18n_parent, it's of course "null" as there is no known parent. Also it's only affecting "create new" which we might can live without. Anyway, I guess it's still not making sense that clicking on "create new" on a german record creates records in default language.

#2 Updated by Marcel Greter over 9 years ago

I found one bug so far :

t3lib/class.t3lib_tceforms_inline.php @ 1139

- if ($parentRecord[$languageField]>0) {
- $record[$childLanguageField] = $parentRecord[$languageField];
- }

+ if ($parentRecord[$parentLanguageField]>0) {
+ $record[$childLanguageField] = $parentRecord[$parentLanguageField];
+ }

Now the newly created relation does inherit the language of the parent record, but the relation record still points to the same entry as the default language. IMO the referenced record should also be translated (copied) and the relation then should point to this new record.

#3 Updated by Marcel Greter over 9 years ago

I guess this is a related bug : http://bugs.typo3.org/view.php?id=9526

I'm now looking into localizeChildrenAtParentLocalization, localizeReferencesAtParentLocalization and localizeReferences. It looks like it actually works now, will report back if I find any more problems.

As a side note, irre expects the localizationMode parameter directly within config and not within behaviour. Irre tutorial always has it within behaviour, so I'm not sure what really was intended. This is at least the case in class.t3lib_tceforms_inline.php @ 1135

if ($config['localizationMode']=='select')

#4 Updated by Marcel Greter over 9 years ago

I attached a patch which does fix the "create new" link to behave as needed for my case.
If you click "create new" in combined edit mode, the new relation and the new record will be set to the language of the current record. IMO the patch is quite clean, but still use it at your own risk ;-)

Hope it's helpfull!

Best wishes,
Marcel Greter

#5 Updated by Andreas Kiessling over 9 years ago

As i had struggled with irre and localization settings, i found this in core api:

"localizationMode ('keep', 'select')
Defines in general whether children are really localizable (set to 'select') or just taken from the default language (set to 'keep'). If this property is not set, but the affected parent and child tables were localizable, the mode 'select' is used by default."

So shouldn't the check look like this?
// Set language of new child record to the language of the parent record:
if (!isset($config['behaviour']['localizationMode']) || $config['behaviour']['localizationMode']=='select') {

Regards,
Andreas

#6 Updated by Andreas Dörler almost 8 years ago

  • Target version deleted (0)

Hi,

are there any current news to this issue?

I see that a last part vo Marcel's patch (v2) seems to be already in the current core (4.5.7), but "if ($config['localizationMode'] == 'select')" is still wrong.

In my case there is no need for "useCombination" but in my 1:n relation new child records are also created with default sys_language_uid instead of the current language.
I'm also wondering wheter it would be possible to remove the "create new records" button in any language than the default, but leave the records itself. This would solve (workaround) my issue, as new records could only be created in default language and localization of them works as expected.

Kind regards,
Andreas

#7 Updated by Stefan Galinski over 6 years ago

  • Category set to 978

#8 Updated by Viktor Livakivskyi over 5 years ago

The issue is still in place with 6.x branch. But now it is even more critical, because developers are switching to Extbase, and wrong sys_language_uid at child record makes it impossible to get this child form parent - even by repository.

This issue is partly related to #40656, which I've reported over a year ago.
And fix for that issue is quite simple, but not enough. Because, even if InlineElement->createNewRecord() sets correct sys_language_uid to a child on creation, saving of a record again leads to sys_language_uid=0 for a child, which is worng and problem persists somewhere in BE DataMapper.

#9 Updated by Jan Greth over 5 years ago

Can confirm this. I have the exact same behaviour and brings much trouble in multilingual sites...

#10 Updated by Teamgeist Medien about 5 years ago

  • Target version set to next-patchlevel

Having the same problem. This fix http://forge.typo3.org/issues/57063 sets the language of newRecords to the parents language but when translating a tt_content element with flexform IRREs, the translated elements IRRE records are the same as the default ones.

#11 Updated by Viktor Livakivskyi about 5 years ago

#57063 is solved, which may lead to closing of this issue.
But there is still a case, when this issue is reproduced even after mentioned fix.
Whenever 'sys_language_uid' field is marked as 'readOnly' in config section, child record again becomes saved with sys_language_uid=0.

This is a common behaviour, since there is no need to allow editors to change language of a localization.

Tested under TYPO3 6.1

EDIT: I was too blind to see the reason. If a field marked as 'readOnly' it is rendered with 'disabled' attribute in HTML, and therefore it's value is not sent to the server. Therefore DataMapper sets sys_language_uid to 0, since nothing comes in POST-request.
But anyway, in my opinioin, DataMapper needs to set explicitly sys_language_uid to value, taken from parent record, if it doesn't appear in POST and is defined as 'languageField' in 'ctrl' section of TCA.

#12 Updated by Helmut Hummel about 5 years ago

  • Status changed from New to Needs Feedback
  • Is Regression set to No

Viktor Livakivskyi wrote:

#57063 is solved, which may lead to closing of this issue.

so we can close it?

But there is still a case, when this issue is reproduced even after mentioned fix.
Whenever 'sys_language_uid' field is marked as 'readOnly' in config section, child record again becomes saved with sys_language_uid=0.

As mentioned on the dev mailing list, this is a different story. Using readOnly for sys_language or l10n_parent fields lead to unexpected results.

Tackling this would be a different issue.

#13 Updated by Viktor Livakivskyi about 5 years ago

Hi, Helmut.

so we can close it?

Yes, becasue this issue is about non-'readOnly' scenario.

But there is still a case, when this issue is reproduced even after mentioned fix.
Whenever 'sys_language_uid' field is marked as 'readOnly' in config section, child record again becomes saved with sys_language_uid=0.

As mentioned on the dev mailing list, this is a different story. Using readOnly for sys_language or l10n_parent fields lead to unexpected results.

Tackling this would be a different issue.

I've just created a new feature request #60026 for this. Feel free to update it with more info, if needed.

#14 Updated by Alexander Opitz about 5 years ago

  • Status changed from Needs Feedback to Closed
  • Target version deleted (next-patchlevel)

Closing as commented.

Thanks for help.

Also available in: Atom PDF