TYPO3 Core

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.

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.

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')

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

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

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.

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

#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.

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.