Support adding new entities when translating

I'm also wondering about this, commenting this out enables asymmetric translations (i.e. you can have different references per language, you can have more references for one specific language). I have noticed this functionality could be beneficial for some projects.

The problem I faced with commenting out this code (I'm using ECK to create custom entities that I want to reference + IEF) is that if I add new references on another language then I can't remove them in the node edit page, I can only delete references on the node edit page on the default language (the references I added on another language obviously don't turn up there anymore). This meant I had to manually remove this content through ECK content list.

Hi, commenting that block for me is working, at least with manual tests.

Without it i cannot add different media images to different translations.

I attatch a patch with the block commented.

Best

ups, wrong patch

update patch now removing that lines

Hey david.gil,

Same issue here, your patch does the job. As we are here, we should also allow removing the reference by removing the '#access' => !$element['#translating'] a bit higher in the same file.

See patch attached with both yours and my fix.

ps: @maesteri - I can confirm David's patch work for me too on real content.

#4 works for me - thanks

This also works for me.

#10 patch seems to work for me.

#10 patch works for me as well

Thanks for feedback.
I'll mark it as RTBC so the maintainer can have a look and hopefully merge it.

Applying the patch #4 works, but it breaks the behaviour of translating a node.

In my case, I have a field reference, that references custom Entities. When translating the node, because of the patch #4, only the first entity will be duplicated in the language of the translation, and all the other entities will lose their default language for the language of the translation.

So if you are going for a multilingual, you should rather use patch #10.

Using a multilingual site #10 did the trick for me.
Since this is in my opinion a rather big issue - any possibiliy of a new release?

possibiliy of a new release?

We explicitly didn't want to allow asymmetric translations, where one language would have a reference that the other language doesn't. This was done to simplify both the UI and the translation logic itself.

If the future maintainer decides to accept this patch, it will need plenty of custom testing, and a review of the existing logic. Leaving the issue open for now.

This is an important feature for our projects and I believe for several others, taking into consideration the number of followers.

Indeed some tests should be written, and I'll try to help with it, but for now I'm just uploading the same patch as #10 so it can be applied to the most recent module version.

I agree with @rutiolma and in my opinion - the better way would be make 'asymmetric translations' optional.
I provide a simple patch for 'Allow user to make asymmetric translation' option for 'Inline entity form - Complex' field widget settings.
And by the way - the patch provide a little tests coverage
so, please take a look)

Just 2 cents, I agree the UI and the simplification of the module make sense. However, asymetrical translations are allowed out of the box in Drupal with entity reference fields. IEF should maintain that support, but agreed that the effort to maintain tests, etc could be pretty great.

I like the optional checkbox. Will test patch here shortly.

The ticket [#2836102} has a good write up on how add/edit behavior should work between different permutations of the field settings and content settings. These would be good to consider when writing tests against the asymetrical translations.

Hello everyone.

#24 works fine for me, but I notice something that may be a issue:

1. Create a node with inline_entity_form and with a content in this inline form (asymetrical checked);
2. Create a translation for the node (but don't change the inline node)

Result: Inline Node has the language changed, and not translated.

I checked the build of the inline form element and in the following code, the translation option is not been defined:

'#translating' => $this->getSetting('allow_asymmetric_translation') ? FALSE : $this->isTranslating($form_state),

Shouldn't this be something like the example below?

'#translating' => $this->getSetting('allow_asymmetric_translation') ? $this->isTranslating($form_state) : FALSE,

So, if the node is being translated, the inline node will also be translated?

I updated the patch #24 with my suggestion.

Updating the patch with the sniffer fixed.

Hi all.

Just notice that I was doing things wrong, and both patches worked fine for me. I'm adding the patch with both changes (#22 and #24) in a a single file.

Thanks.

Hi.

I was running tests with those changes, and notice that I still have the issue that the node in inline form have its languages changes instead of being translated. Does anybody is having this issue as well?

I apply the change I propose in #27, and seems to fix the issue.

Sorry for the amount of patches and comments on this one =/.

Geovanni, does #2948497: Entity references should respect parent's source language seem like the same issue?

Patch "Assymetric_Preview_issue-2822764-34.patch" is wrong. Sorry about that :)

When adding a translation to an entity with IEF widget with enabled "Allow user to make asymmetric translation", wrong translation is used for preview.

Steps to reproduce:
0. Configure a multilingual website
1. Create Translatable Entity reference field
2. Select "Inline entity form - Complex" widget for it
3. Edit widget settings and enable "Allow user to make asymmetric translation"

4. Create a new Content
5. Add translation
6. Update translation by editing the referenced entity
7. Reload the page to load initial table

Expected result:
The preview table has translated titles

Actual result:
Titles are output in default language.

But when clicking "Edit", IEF provides correct values in form for the language.
And after updating the entity, the updated preview has also correct language.

A little rewrite of #24 to resolve the translation issue from #34
Since we are introducing a new option, it is better to use it separately to prevent ambiguity.

WRONG PATCH

Sorry, about patch-bombing. Late night, missed initial case.
Update of #35.

With the latest patches I'm not able to add or remove entities when translating if the reference field is not translatable. So adding or removing is only possible if you edit the default translation or if the reference field is translatable.

Not translatable fields should be editable in translations too. At least this is the common behaviour for fields of type text, number, etc.

In the use-case I'm looking at, we're using Bricks and ECK.

In that circumstance, one or another of those layers is not allowing translation of the entity references to be symmetric, so the end result is that the user has a bunch of orphaned bricks in the translations if they delete them from the primary content.

Being able to delete these is the best workaround ATM. The patch in #36 helps that.

Here's a little bit of a review:

+++ b/src/Plugin/Field/FieldWidget/InlineEntityFormComplex.php
@@ -217,6 +231,7 @@ class InlineEntityFormComplex extends InlineEntityFormBase implements ContainerF
       '#translating' => $this->isTranslating($form_state),
+      '#allow_asymmetric_translation' => $this->getSetting('allow_asymmetric_translation') || !$this->isTranslating($form_state),

$this->isTranslating() ends up calling a bunch of other services, so we should only call it once.

And a patch for #39.

Patch from #40 works fine for me on ief 8.x-1.0-rc1.

Patches work well for me when it comes to translate related entities but I still don't get the "Expected Result" mentioned on comment 34 so I'm always getting the default language entity title.

I'm attaching an improvement to 40, which adds a contextual translation to the referenced entity.
I don't see another way of doing it since the information passed to the field is only entity_type:id, no langcode information provided.

I also realized, that after creating a new translation for a node, the referenced entities don't get translated to the new language. You will end up with a "parent" node in the new language referencing entities in the original language.

In order to get also the referenced entities translated, I had to manually edit and save every referenced entitiy in the inline forms widget and then save the translated parent node.

I didn't want to patch inline_entity_form module so I used hook_entity_translation_create on the parent node type to automatically add AND save translations for the referenced entities. So I don't have to edit/save all related entities manually.

The code in the hook looks something like that:

use \Drupal\Core\Entity\EntityInterface;

/**
* Implements hook_entity_translation_create(\Drupal\Core\Entity\EntityInterface $translation)
* when a new translation for an appointment is created, make sure to create a translation for all related appointment dates too.
*/
function mymodule_entity_translation_create(EntityInterface $translation)
{
	//apply only to entities of type appointment
	if($translation->getType() == 'appointment')
	{
		//get the translation language that was just created
		$newTranslationcode = $translation->language()->getId();

		//find all referenced appointment date entities, 
		//create a translation, copy values to new translation and save translation
		foreach($translation->field_termine as $termin)
		{
			//failsave, make sure no other entity types are referenced from appointment dates field
			if($termin->entity->getType() == 'appointmentdate')
			{
				//only add this translation language if the entity does not already have it
				if($termin->entity->hasTranslation($newTranslationcode) == false) {
					//copy all (field) values from source termin and save translated termin entity.
					//$values = $termin->entity->getUntranslated()->toArray();
					$values = $termin->entity->toArray();
					$termin->entity->addTranslation($newTranslationcode, $values);
					$termin->entity->save();
				}
			}
		} //eof foreach termin

	} //eof content type ==  appointment

}

Patch #22 Worked form me. Thanks.

#42 on current DEV release works well for me.
Just Check "Allow user to make asymmetric translation" on Manage Form Display.
Don't forget the nested fields to configure.
If the checkbox is missing, check your field settings. Probably it's not marked as translateable.
Cheers & Happy We

Why does this patch add a checkbox "Allow user to make asymmetric translation"? That is very confusing to me as the core behaviour (and that of (nearly) all contribs) is that a field is async the moment you set it as translatable. I fail to see the point of having a translatable field, that is not async. What exactly would an end-user be able to do with that? What could that user then translate that wasn't translatable before?
Just asking questions, because to me it seems like a checkbox that is not needed and just confusing ;)

#42: This seems to me like it has nothing to do with the field being async or not. Shouldn't we be fetching the correct translation for the entity in both cases? Isn't that how an entity reference field works regardless of which form widget you chose? So, in short, shouldn't that issue be separated from this issue?

@weseze asymmetric translation allows you to have different references per language in a variable number (i.e. EN translation can have 1 reference and FR translation can have 2 references)

Regarding the path at #42, I agree that if there are issues regarding translations in the referenced items, they should be on another ticket.
I'm uploading an updated patch, which works with the newest version of IEF.

@rutiolma: "asymmetric translation allows you to have different references per language in a variable number"
That statement is correct, no discussion there ;) But...
That is what core does with all fields when you enable translation, by default. Try creating a number field with multiple allowed values and enable translation for it. You can then create 1 number for EN, 3 for FR, and so on... In my opinion async is the default behaviour and sync should be the optional one with a checkbox.

Thanks for the patch!

I'm trying to understand if the behaviour I see is a bug or a feature.
I have a node type with the reference field to media entity and I have "asymmetric translations" allowed.
So when I create a node in English and create a media entity and then I create a translation of that node and I delete a referenced media in the translation and create a new one my original media entity got deleted, but I don't want it deleted. I want that I will be used in English version and translation have it's own, another media.

Am I doing something wrong?
Is it possible to prevent referenced entity deletion if it is used in another translation?

Well this is my two cents.

This patch adds a check that entity being removed is not referenced in any other translation of the parent entity, if that is translatable.

This is obviously work in progress, but review/feedback is much appreciated!

Re-rolling #52 to work with 8.x-1.x. Only change seems to be moving the tests.

Patch #53 fail to apply with the last 1.0.0-rc6. Is the issue solved?

Patch #53 fails to apply also with the latest dev

So needs rebase.

rebased - I tried it, it seems to work as well as #53. Only src/Form/EntityInlineForm.php really needed manual merging.

Run bot!

errr... I don't understand "run bot!"

Patch from comment# 32 modified for Drupal core 8.8.0

Apologizes for this comment! Tried to change patch file name.

@sastha: hi, why are you referring to french translation on your patch (#61) ?

Hi @FiNeX,

I just took patch #32 and fixed it for 8.8.0. French translation is part of patch #32. Please check.

@sastha, I do not understand why you choose to ignore all the work done since #32. I strongly recommend to either continue to work from #57 or explain what is wrong with the changes made since #32.

@Sutharsan, For my requirement, I have used patch #32 with few changes to support latest core with minimal testing. My mistake I shouldn't have shared the patch. Apologizes!

Uploading rerolled patch.

Please review the patch.

Thanks for rerolling the patch @neelam.chaudhary

#67 works for me on Drupal 8.9.13 and IEF 8.x-1.0-rc8

@Suresh PRabhu Parkala can you explain what is the point of your patch?

After a more thorough check, I'd like to recall my last comment.

In fact, @neelam.chaudhary, your patch in #67 doesn't respect the new setting: allow_asymmetric_translation

i.e. fields have asymmetric translation enabled regardless of what is chosen in the field widget.

Also, can you explain why the need to reroll the patch?

I'm sticking to #57 for the meantime, since it still works fine and it looks like the way to go in my opinion.

Let's resume: In #58 we had a 15k patch, #60 is 5k ("#32 backported" but no explanation why) and now it's 2k, everything without explanation.

People, that's a holy mess, and a bunch of anti-credits and really bad karma piles up here.

Please clean up the mess.

Is anyone going to address my comment in #47 and #50? Why is a default core behaviour, for how translatable fields work, being changed for this specific module? Or am I wrong and is everyone too polite to point it out to me?

@weseze There is a similar discussion about symmetrical versus asymmetrical translations with regards to Layout Builder. See #3044386: [META] Make Layout Builder layouts translatable.
As I understand, the benefit of having symmetrical translations is that we use a single reference for multiple languages. The referenced entity will have translation enabled on a per-field basis. This could allow some fields to be translated whereas some are not. So that's a valid use case IMO.

This is just an update to clear the ticket a bit.
Patch #60 was a mistake as stated at comment #65.
All the patches that followed were based on this patch so they should be ignored. The correct patch to use at this point is #57, which takes in consideration all the work done since #1.

I'm removing the problematic patches from display. Any new patch should be based on #57 and interdiffs would be great.

Thanks for the patch @Suresh PRabhu Parkala

#69 works for me on Drupal 8.9.16, PHP 7.3 and IEF 8.x-1.0-rc9

Hi!:
patch #57 works for me in drupal 8.9.18 and php 7.4.14 with IEF 8.x-1.0-rc9

We have tested patch #57 on drupal 8.9.18 | php 7.3.29 | IEF 8.x-1.0-rc9

I agree with @weseze that this module should follow the expected behavior for all Drupal reference fields, but realize that this update might not be feasible in a minor version bump.

I would suggest that we get more testing on patch #57 and push forward with the goal of getting this improvement in the new minor release while the question of expected behavior continues.

About patch #57, this does not work with nested Inline Entity Form.

In delete(), the $context variables is:
- parent_entity_type: paragraph
- parent_entity: a node instance
- field_instance: FieldConfig instance (nested: id = paragraph.content_featured_custom.field_ref_featured)

I don't have time yet to work on a (possible?) updated patch.

After spending several hours debugging, I don't know how to fix #80. I will simply leave here my review.

1. +++ b/src/Plugin/Field/FieldWidget/InlineEntityFormComplex.php
   @@ -401,15 +421,16 @@ class InlineEntityFormComplex extends InlineEntityFormBase implements ContainerF
   -            '#access' => !$element['#translating'],
   +            '#access' => $element['#allow_asymmetric_translation'],
   ...
   -    if ($element['#translating']) {
   +    if (!$element['#allow_asymmetric_translation']) {
   

   This changes the current behavior if asymmetric translation is not enabled. In both cases, if it is not in the translating, the element/delete button must be displayed.

2. +++ b/src/WidgetSubmit.php
   @@ -53,7 +53,13 @@ class WidgetSubmit {
   +          'parent_entity' => $form_state->getFormObject()->getEntity(),
   

   'parent_entity' of the form object is the "root" parent, not the direct parent of that field. For instance, in a node => paragraph => entityA setup, the parent_entity_type is "paragraph" (correct) but the parent_entity should not be node.

This takes care of the parent_entity issue, by setting it during the widget InlineEntityFormBase::prepareFormState() function.

Other notable changes compared to the #57 patch:
- Removed the parent_entity_type from the delete context (redundant when the parent entity is available).
- Issue with deleting entities that didn't support revisions.

This issue has been open for quite a long time, and neither patch 82 nor 57 worked for me. Is there something else that needs to be updated after applying the patch??

I have a node, with media references, using Inline Entity Form. The media field is set as translatable, and the user can "add existing items" and browse the media entities to select them. But the "Add existing entities" button ONLY appears on the initial English node, and not on any translations, whether new translations or existing translations!

We need media items in specific languages on specific pages. How can this be accomplished with IEF?

-Jenny

@jennypanighetti you should check "Allow user to make asymmetric translation" in Manage form display settings on that specific reference where you have selected to use IEF.

But anyways it sounds that by design you loose translation track and if references matters in different languages - better avoid this solution.
https://www.drupal.org/project/inline_entity_form/issues/2983389 comment says that by design you should avoid translating reference field. I'm about to go this way.

This looks like a OK solution, as #83 mentions, it doesn't seem to be another way to do this with IEF (except from adding a link to an external page). So maybe if this won't get in IEF, we could have a ief_asymmetrical like happens with LB

Hi,

Used patch from #82 and works perfectly on my project. Now I can operate with relation to add, edit or delete a new relationship.
I think it is ready to be added.

This is complex. IIRC there is a analogous issue for paragraphs. This issue might profit a lot from the other, so crosslinking and analyzing appreciated.

Hi everyone, thanks for your work.
This is a reroll of #82 against 1.0-rc12.

Hi everyone!
I'm using the current rc12 version of the module with the applied patch from https://www.drupal.org/project/inline_entity_form/issues/3197629 (#8).
In this case patch #89 can not be applied so I did a small reroll against it.

Patch #90 failed: inline_entity_form version is 1.0.0-rc12 (Drupal 9.2.21). Good news is that Patch #89 worked

@bennyjos I think #90 differs from #89 so that it can be applied if the mentioned patch #3197629-8: New API hooks to react on inline entity save/delete is already applied (hence the Patch Failed to Apply statement).
Is that correct, @Goodmood?

So IMHO we should use #89 for further discussion.

Patch #89 does not work for 8.x-1.0-rc14 with Drupal 9.5.3 (it can be applied but it does not solve the problem).

I did not find any other patch or any other solution.

Does anyone have an idea how can I solve this?
Thx.

#93 solved:
"Allow user to make asymmetric translation" has to be activated on Manage Form Display of the conent type.

While testing this patch out I noticed that if the language of the content is changed this does not work quite well with referenced entities and sometimes their language gets changed as well or sometimes the entity remains in its original language and then differs from the one of the content after save ... We should not be assuming that we can simply change the language of the referenced entities since suddenly they might not get displayed in other places if they are reused. Instead, we should be translating them as this is the safe option. Worked on #3342727: Main entity language change does not propagate to nested paragraphs in preview mode for adding support for propagating the language change and adding support in the patch here as well. I am not sure if this is the right issue though or if another is needed for this.

There is a failing test about the same langcode for child entities. IMHO, it's not "valid", because this patch is in the way to allow having asymmetric content. I've removed some lines. Feel free to improve/blame :)

Forgot to remove a line.

Updating version to the latest dev

I've prepared a merge request to the 2.0.x-dev branch with an updated patch. For me it works well, appreciate it if anyone else could test it.

Also, attaching a file version of a patch in order to run some tests (cuz it seems for the 2.0.x-dev branch we have disabled tests running).

I'm still using rerolled patch from #90 (due to the same reason which mentioned there) over rc15 and D10.

With Drupal upgrade we have an exception when entity removed from ief widget and parent entity saved:
"Entity queries must explicitly set whether the query should be access checked or not"
This is because of absent accessCheck method on query in 'delete' method.
Added this check to patch from #90

Also this should be added to patch #99 because otherwise it'll throw an exception on D10 as well.

Sorry, wrong file was attached

I create a new patch for drupal 10.1.x, thanks for @quadrexdev, the #103 is useful for me. At the same time, I merged the patch in this issue Parent form entity builders run on IEF resulting in fatal errors into the new patch.
And I added the code for checking entity langcode and form langcode to get the corresponding entity.

I could not apply the #106 patch on Drupal 9.5.9 with PHP 8.1 using IEF 8.x-1.0-rc15. Was anyone able to use this patch cleanly?

Is https://www.drupal.org/project/inline_entity_form/issues/3197629 (#8) a prerequisite for #106? Please advise.

Indeed the #106 patch is already based on the one you linked @drupalevangelist.

Here's the one that does not need any pre-patch :)

Thank you! I was able to apply cleanly #111 patch on 8.x-1.0-rc15. But now I'm not encountering the following error when I try to create nodes using certain content types that has the Inline Entity Form widget configured:

Error: Call to a member function bundle() on null in Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection->stripAdminAndAnchorTagsFromResults() (line 289 of core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php).

I found this issue here - https://www.drupal.org/project/drupal/issues/3341448 and not sure what's going on since I'm already on D9.5.9.

111 did not worked on 1.0-rc15 so I made some slight alterations for anyone interested.

Reroll against 3.0.0-rc19

Refactored patch because of failed PHPLint in #114

Fixed broken asymmetric translation tests

Adding refactored patch for the 3.x branch (c753ec1).

Here's the follow-up update to the patch in #117.

- The following code is reinstanted back to InlineEntityFormComplex.php file as removal of these caused namespace reference loss for existing code:

use Drupal\Component\Utility\Tags;
use Drupal\Core\Entity\Element\EntityAutocomplete;

This is the patch is the same as #118, but rerolled for 3.x-rc19.

The patch is same as #113, re--rolled it for 8.x-1.0-rc17

The latest commit of https://git.drupalcode.org/issue/inline_entity_form-2822764/-/tree/2822764-support-adding-new-entities-when-translating applies cleanly to 3.0.0-rc20 as a patch. I made a small change to remove @label from the translatable markup that was never actually getting replaced.

The failing TranslationTest needs to be fixed and it seems to me that this patch has unintentionally changed the behavior even when allow asymmetric translations hasn't been enabled as the test fails on line 108 which is well before we enable it.

    // Both inline nodes should now be in English.
    $first_inline_node = $this->drupalGetNodeByTitle('Kann ein Känguru höher als ein Haus springen?');
    $second_inline_node = $this->drupalGetNodeByTitle('Can a kangaroo jump higher than a house?');
    $this->assertSame('en', $first_inline_node->get('langcode')->value, 'The first inline entity has the correct langcode.');
    $this->assertEquals('en', $second_inline_node->get('langcode')->value, 'The second inline entity has the correct langcode.');

#126

The website encountered an unexpected error. Try again later.

Error: Call to a member function isTranslatable() on null in Drupal\inline_entity_form\Form\EntityInlineForm->delete() (line 346 of modules/contrib/inline_entity_form/src/Form/EntityInlineForm.php).
Drupal\inline_entity_form\WidgetSubmit::doSubmit()
call_user_func_array() (Line: 113)
Drupal\inline_entity_form\ElementSubmit::doSubmit() (Line: 83)
Drupal\inline_entity_form\ElementSubmit::trigger()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult() (Line: 39)
Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 704)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Looks like this patch was on the right path from #95 and then veered away from it. I strongly agree with #95 that we should be translating entities rather than changing their langcode as that is destructive and would confuse editors. I believe the fix in #52 might have been trying to address that but it may be redundant now. Also, it only prevents deleting entities used by the parent node but that could mean they are still deleted if referenced by other entities. Heavily based this MR off #95.

Changes in MR 120:

1) Inline entities are translated rather than having their language changed.
2) Re-attached the submit handler from #95 that was removed and handled the case where the main entity form is submitted but the inline entity form hasn't been opened yet.
3) Removed the deletion code that was trying to prevent entities being removed if referenced by the parent entity (I think that is probably better handled by something like entity_reference_integrity module). See above for reasons.
4) Translations get their own created/updated timestamps when they are created rather than inheriting from the default translation. This helps them show up in the /admin/content view when the parent page is translated.
5) Rename the testTranslation test to testSymmetricTranslation and added cases for translations and timestamps. Also created a new testAsymmetricTranslation test to test asymmetric behaviors which was more thorough than the previous behaviour.

Feedback welcome.

Regarding the comment in #127 the line number you indicated the error on doesn't match up with my MR so I don't think its related. Anyway I'm working on MR 120 now.

One more update on #129, I have a use case that on certain languages that are English language variants e.g. en-GB and translate from a default en node, that the IE shouldn't be translated to en-GB by default. Rather than translations, they are localizations. Currently a new translation would be copied from the en inline node, and the languages would split, so it's not possible to share content across languages.

In this case, en-GB should still be able to reference en nodes without translating them. There could be other use cases, so the most flexible way is to introduce a new ShouldTranslateEvent that gets dispatched just before translation but keep the behavior described in #129.

I am adding a static patch 2822764-129.patch based on #129 / MR #120 for 3.0.0-rc20.

Looks like this patch will make previously created translations not have a value.

@jksloan2974 do you mean the patch from #131. Do you have any steps to reproduce? I think if you were to apply that patch to a site that was using the previous method from an earlier patch (where the language of the entities was changed rather than translated) I could see that happening but not sure how it would occur on a fresh site.

I think it is because I have an inline entity form reference to an eck inside a paragraph. I will see if I can generate steps to reproduce

Ok after doing a bit more research it appears at least in my example. Content and translations were created before the field was set to be translatable. Once I went into the field settings and made the field translatable that is when the translation will not display the fields any more.

Does anyone know if there is a way to fix the issues describe below?

1. Entity reference field referencing ECK is set to not allow translations (created through IEF - when creating node)
2. Content is created
3. Entity Reference Field allow translations is turned on
4. Translations are now missing the Entity Reference field that was created in step 2.

Is there an automated way to create those translation that are now missing?

With the issue above I was also having this when moving a paragraph field to translate. Someone created a patch that when a asymmetric paragraph get turned on to translation content will be migrated to it's own translation.

https://www.drupal.org/files/issues/2023-06-07/2992777-paragraphs_asymme...

We are also experiencing issues with this patch https://www.drupal.org/files/issues/2024-12-17/2822764-129.patch
InvalidArgumentException: Invalid translation language (und) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 985

When using 3.x dev version with patch https://www.drupal.org/files/issues/2024-02-23/inline_entity_form-282276...
things work as intended....at least for our setup. Entity reference field on a node and translations disabled

Thank you to everyone trying to fix this problem.

We had encoutered some very weird issue with the MR120 and 3.x where configuration forms where not being saved.

The most problematic one was "Content language and translation" /admin/config/regional/content-language where you couldn't change the value of a field translation.
Go to this config form, open the "Content" accordion, then choose a CT (article for example) and check or unchecked the title to make it not translatable anymore, then save.
When the page reload, the title won't have its status changed.

If you remove the MR, then the form works again.

We also encountered this on media_directories module in the UI section and it seems to affect nested configurations.

So for the moment we're sticking to 8.x-1.0-rc17 and patch #113.

Due to this problem which seems pretty important, I'm switching the status to Needs Work.

Thanks for the steps to reproduce @tostinni. I just tried toggling the translatability of the Article title field but it was correctly saved. I'm using IEF 3.0.0-rc20 and Drupal core 10.3.14. Might be a version thing or another conflicting module? Hard to say. If other people could test that would be great.

@undersound3 #138 What were you doing when that issue occurred. Does the parent node or the inline entity you're trying to translate not have a source language set? i.e. und. There are quite a few core/contrib issues about the same thing so it might be something that needs to be accounted for

When using nested content blocks and Complex widget in Layout builder, the following error occurs:
Error: Call to undefined method Drupal\layout_builder\Form\UpdateBlockForm::getEntity() in Drupal\inline_entity_form\Plugin\Field\FieldWidget\InlineEntityFormComplex->extractFormValues() (line 731 of /data/sites/web/xxxxx/web/modules/contrib/inline_entity_form/src/Plugin/Field/FieldWidget/InlineEntityFormComplex.php).

There is no getEntity-method for the layout builder form which triggers an error here:

$main_entity = $form_state->getFormObject()->getEntity();

Created a patch based on https://www.drupal.org/project/inline_entity_form/issues/2822764#comment... and combined with the Call to undefined method getEntity when using in Layout Builder as mentioned in https://www.drupal.org/project/inline_entity_form/issues/2822764#comment...

Drupal 10.4.6 here, same issue.

Any chance I could apply one of the proposed patch?

I agree with comment #139, I came across it by accident.
The following code causes this behavior (in inline_entity_form.module):

  // A translation submit handler for the case where the main entity
  // changes its language code but the widget is not active.
  WidgetSubmit::attach($form, $form_state, TRUE);

@achap This code overrides the #submit callback, which prevents content_translation_form_language_content_settings_submit from being called in content_translation.admin.inc (line 167).

@achap Attaching a screenshot.

Hi @usingsession,

I tried to reproduce locally on core 10.4 but I couldn't again in my case it appends the submit handler rather than replacing it... however given that two people have said this is happening I will take your word for it and I moved the attach method so it's only triggered if an IEF is present. I'm not sure why that was there but I did base this patch on #95. Simply removing that line caused a test fail, but locally it passed by moving it up into the check. Are you able to check if it's working for you now?

I also updated the MR to include a check for instances where the form object isn't an instance of EntityFormInterface like in #142 with layout builder. That stops the error but given that the subsequent code doesn't execute it might not work correctly. I don't use layout builder though, so not sure. This part might still need some work.

Hi @achap,

I checked Merge Request !120 – the "Content language and translation" form is being saved successfully.

"Support adding new entities when translating" also seems to be working correctly.

Thank you

Added a new commit to MR 120 that fixes an issue where if an entity makes use of the "Hide non translatable fields on translation forms" the translatable fields are hidden even when creating a new node via IEF on a translation of the parent entity.

Created patch from the latest version of MR#120.

Drupal version 10.5.6

Issue Summary
Inline Entity Form Complex contains this logic:

if ($element['#translating']) {
if (empty($entities)) {
RenderArray::alter($element)->restrictAccess(FALSE, NULL);
}
return $element;
}

Problem
When translating a node, if the field has no existing referenced entities, IEF hides the widget completely.
This makes it impossible to add new items (Bricks, Paragraphs, Entity Browser entities, etc.) on translated nodes.

In my scenario
In my case, I needed to add new Bricks on the translated node, not just edit existing ones — but because $entities was empty, IEF hid the entire widget and blocked the workflow.

Expected behavior (In my case)
Allow editors to add new referenced entities during translation, even when none exist on the source language.

Solution
Commenting out the access restriction inside the translation block keeps the widget visible and allows adding new entities during translation. This worked for me.

https://www.drupal.org/files/issues/2025-12-10/2822764-150.patch

The simple approach in the patch in #150 solves the issue that a field with "Inline Entity Form - Complex" widget on a translation form would not show, when this field has no value in the source translation node, even if the field is translatable.

Hello,

I use Drupal 11.3.2 and inline_entity_form 3.0.0-rc21.

I am getting an error when translating a taxonomy:
Error: Class ‘Drupal\inline_entity_form\Event\ShouldTranslateEvent’ not found in Drupal\inline_entity_form\TranslationHelper::prepareEntity() (line 47 of modules/contrib/inline_entity_form/src/TranslationHelper.php).

Indeed, this class ‘ShouldTranslateEvent’ does not exist...

None of the above patches work.

Does anyone have a solution?

Thanks

I used the patch 150 and I'm able to add existing and new bricks again. One thing that is missing from 89 that I was using before upgrading is the ability to delete. I don't have the option to Remove any of of the bricks/entities under the Operations column. I only have edit.

I adapted the patch in #149 for the 3.0.0 version of the module. (tested on 10.6.10)

Providing a patch for this MR for v3.0.0-rc21

Providing a patch for this MR for v3.0.0-rc21

Providing a patch for this MR for v3.0.0-rc21