When you're inline editing entities, the language of the parent entity is to be respected.
1) if you're editing an english node, newly added products also have "english" set as their language.
2) If you're using Entity Translation and adding a french translation for the node, then the product values should be saved under "fr" as well.
(Assuming ET is enabled for both entity types).

#1 has been fixed in #1558632: Pass correct langcode to field_attach_form, newly created entities.. This issue is for #2.
Related issue in the ET issue queue: #1865244: Allow multiple translation handlers on the same form.

Original issue

Right now IEF doesn't care about the product language (doesn't touch it if it's set, sets it to LANGUAGE_NONE if it isn't).
It should care, showing and editing the products in the language of the parent entity.
So if the widget is shown on the french translation of a parent entity (node translation or entity translation, irrelevant), then it should manipulate the french values of the child entity fields.

Of course, it should work for any entity type (inline and parent). That's why we need entity_language() to land in D7 core.

Postponed on the D7 core issue: #1495648: Introduce entity language support and the entity_translation issue: #1282018: Improve UX of language-aware entity forms (since it's a big patch that would require us to retest and probably rework pieces).

#186 inline_entity_form.info.rej_.txt422 bytesvensires
#184 interdiff-1545896-add_entity_translation_integration-174-184.txt2.2 KBSkabbkladden
#184 inline_entity_form-add_entity_translation-1545896-184.patch48.06 KBSkabbkladden
#181 interdiff-1545896-add_entity_translation_integration-174-181.txt2.2 KBSkabbkladden
#181 inline_entity_form-add_entity_translation-1545896-181_with_packaging_info.patch48.74 KBSkabbkladden
#181 inline_entity_form-add_entity_translation-1545896-181.patch48.05 KBSkabbkladden
#174 inline_entity_form-add_entity_translation-1545896-170_174.interdiff.patch3.92 KBvitalie
#174 inline_entity_form-add_entity_translation-1545896-174.patch47.93 KBvitalie
#170 inline_entity_form-add_entity_translation-1545896-170.patch45.93 KBstefanos.petrakis
#170 inline_entity_form-add_entity_translation-1545896-170_tests.patch16.31 KBstefanos.petrakis
#170 inline_entity_form-add_entity_translation-1545896-170_enable_test_dependencies.patch401 bytesstefanos.petrakis
#168 interdiff-167-168.txt2.68 KBalinaBasa
#168 inline_entity_form-add_entity_translation-1545896-168.patch29.62 KBalinaBasa
#167 interdiff-152-167.txt857 bytesXenza
#167 inline_entity_form-add_entity_translation-1545896-167.patch29.61 KBXenza
#158 inline_entity_form.jpg98.88 KBmrchristophy
#155 Edit Article Article Test 2 [Chinese, Simplified] | Sandbox 2016-11-25 17-57-10.png5.72 KBmrchristophy
#152 interdiff-144-152.txt4.66 KBxaa
#152 add_entity_translation-1545896-152.patch30.2 KBxaa
#150 1545896-inline_entity_form-add_entity_translation-150.patch4.66 KBxaa
#144 inline_entity_form-add_entity_translation-1545896-144.patch29.83 KBadinac
#140 inline_entity_form-add_entity_translation-1545896-140.patch29.83 KBgarphy
#136 inline_entity_form_d7_entity_translation-1545896.patch32.27 KBMusa.thomas
#125 inline_entity_form_d7_entity_translation-1545896.patch33.41 KBMusa.thomas
#124 inline_entity_form_d7_entity_translation-2028711.patch33.41 KBMusa.thomas
#123 inline_entity_form_d7_entity_translation-2028711.patch33.4 KBMusa.thomas
#108 inline_entity_form-entity_translation-1545896-110.patch29.79 KBaarnau
#102 interdiff-1545896-99-102-do-not-test.diff1.35 KBdas-peter
#102 inline_entity_form-entity_translation-1545896-102.patch29.72 KBdas-peter
#100 d7_ief_et_autogenerate_title.patch30.32 KBhnutu
#99 d7_ief_et.interdiff.txt1.57 KBfago
#99 d7_ief_et.patch28.52 KBfago
#93 d7_entity_translation.interdiff.txt804 bytesfago
#92 d7_entity_translation.patch28.53 KBfago
#91 d7_entity_translation.patch28.48 KBfago
#88 inline_entity_form-entity_translations-1545896-88.patch17.21 KBa.milkovsky
#86 inline_entity_form.zip44.06 KBdeelite
#77 inline_entity_form-entity_translations-1545896-77.patch17.17 KBheathdutton
#72 inline_entity_form-entity_translations-1545896-65.patch17.58 KBmarabak
#66 error.png23.61 KBgge
#64 inline_entity_form-entity_translations-1545896-64.patch18.69 KBparavibe
#62 Screen Shot 2014-12-08 at 20.08.23.png101.3 KByannickoo
#55 interdiff.txt841 bytesgarphy
#55 entity-translations-1545896-55.patch17.25 KBgarphy
#48 interdiff.txt1.39 KBgarphy
#48 entity-translations-1545896-48.patch17.24 KBgarphy
#46 entity-translations-1545896-46.patch18.27 KBrsmylski
#44 Schermafbeelding 2014-01-15 om 20.02.53.png46.82 KBJeroenT
#41 entity-translations-1545896-41.patch18.31 KBrsmylski
#40 entity-translations-1545896-39.patch17.73 KBrsmylski
#37 2013-10-11 17_33_02-The page at local.sallyhansen.com says_.png3.33 KBPere Orga
#36 ief-entity-translation-integration-1545896-36.patch14.69 KBmurfi
#33 ief-et-1545896-33.patch14.3 KBplach
#20 ief-et-1545896-20.patch14.23 KBplach
#15 1545896-15-am.patch7.53 KBjherencia
#15 1545896-15.patch7.04 KBjherencia
#13 ief_subentity_language-1545896-13.patch7.02 KBitamar
#11 ief_subentity_language-1545896-11.patch6.87 KBitamar
#10 ief_subentity_language-1545896-10.patch7.09 KBitamar
#9 ief_subentity_language-1545896-9.patch1.81 KBitamar
#7 Selection_081.png50.24 KBitamar
#7 Selection_082.png27.36 KBitamar
#7 Selection_083.png28.85 KBitamar
#7 ief_subentity_language-1545896-7.patch4.12 KBitamar
Members fund testing for the Drupal project. Drupal Association Learn more


bojanz’s picture

Some notes from DamZ:

so _field_invoke() doesn't pass the original $options['language'] to field_default_form()

basically, field_attach_view() does:
// languages available in the field data.
  $display_language = field_language($entity_type, $entity, NULL, $langcode);
  $options = array('language' => $display_language);

$langcode is the "language we asked the entity to be displayed in"
$display_language is the "language we have decided to display the field in, based on $langcode and the languages available in the field"
the problem is that the original $langcode is currently lost

$langcode you get from the widget is the language of the *field*, after fallback
 in your case it's probably always going to be LANGUAGE_NONE
because the reference field itself is not translatable (ie. you don't have a different *list* of products per language)

right now what you could do is delay the generation of the form (ie. just return from hook_field_widget_form() a dummy form element with a #process function), implement hook_field_attach_form() to store the proper language (you actually know it then), and generate the proper form based of this information in the #process
dimitriseng’s picture

Status: Postponed » Active

FYI, #1495648: Introduce entity language support is now commited to Drupal core. Can this issue be progressed now or we also need to wait for #1282018: Improve UX of language-aware entity forms to be commited as well?

bojanz’s picture

We can move forward.
I'm not actually sure we even need entity_language() at this point, according to notes in #1. It's a tough problem :)

bojanz’s picture

dimitriseng’s picture

Just checking if there is any progress in making this work properly for multilingual sites...

amitaibu’s picture

Assigned: Unassigned » amitaibu
itamar’s picture

The patch sets inline entities' language to the parent's language, in case the parent entity is already created.

Notice the patch relies on http://drupal.org/node/1495648 (The entity_language function).

Creating an article with a specific language.
Creating an article with a specific language.

Creating a product while editing the article with the inline entity form.
Creating a product while editing the article with the inline entity form.

The inline product was created with the correct language.
The inline product was created with the correct language.

amitaibu’s picture

Next is to make sure language is handled correctly when entity still doesn't exists (e.g. node/add/parent-entity)

itamar’s picture

An improved and simpler version of the previous patch;
Adding a validator to forms having an inline-entity-form that iterates the inline entities and set their language to the language selected on the original form.
- Now it works right both when editing a parent entity and when creating a new one.
- Doesn't rely anymore on entity_language() but rather on the language selector of the form.

I'll add some tests soon.

itamar’s picture

Status: Needs work » Needs review
7.09 KB

Re-rolling the previous patch with some tests for the inline entity language.

itamar’s picture

Re-rolling the previous patch with a little cleanup on the tests (Removing unused dependency on i18n_node and some widget definitions).

amitaibu’s picture

Status: Needs review » Needs work
+++ b/inline_entity_form.test
@@ -0,0 +1,134 @@
+    variable_set('language_content_type_parent', 2);

What's this for? (add comment).

+++ b/inline_entity_form.test
@@ -0,0 +1,134 @@
+    // 1. Create a parent and child nodes with a specific language, make sure

Lets remove then numbering (1.) from comments.

+++ b/inline_entity_form.test
@@ -0,0 +1,134 @@
+    $nodes = node_load_multiple(array(), array('type' => 'child'));
+    $this->assertTrue(count($nodes) == 1, t('A child node was created by the inline form.'));
+    $l0_child_node = reset($nodes);

I don't think we need this, as we know the node ID is 1.

itamar’s picture

Status: Needs work » Needs review
7.02 KB

Fixing the patch according to comment #12, except of the third comment

I don't think we need this, as we know the node ID is 1.

I still load the nodes using node_load_multiple, in order to be independent on whether IEF creates the inline entity before or after the main entity is created.

amitaibu’s picture

Can you "Enable automated testing"?

jherencia’s picture

7.04 KB
7.53 KB

Ok this is a rerolled version.

I've been working in a multilingual application and this patch is needed (and works great) to make entity_translation and IEF work together.

For those who want to test entity_translation, it is needed this patch (#1778662: Add compability with field widgets that uses limit_validation_errors) which is already committed in the latest dev version.

idflood’s picture

I have tested the patch in #15 and it works great (1545896-15.pach).
The only problem is that it doesn't really cover my use case. I hoped that this would have allowed translation of the referenced entities. If I understand correctly this patch does this:
- Create references with the same language as the parent node
- List only the references which have the same language as the parent node.

Am I missing something?

dimitriseng’s picture

It would be great to get this done, this is a great module and would make it usable in multillingual sites. I will give #15 a test and report back. In the meantime, is everybody happy that #15 is the right approach? What about the comments in #16? Thanks.

cocoshogo’s picture

Sorry if this is not a valid question for this conversation, but would this allow a translatable product type, so that if the user language, or product language is x then the "x" translation of the product type select would display the "x" translation of the product type to be used to create the product in "x" language?

bojanz’s picture

Title: Make IEF language aware » Add Entity Translation integration
Assigned: amitaibu » Unassigned
Category: task » feature
Status: Needs review » Active

Yes, that's right.
When you're inline editing entities, the language of the parent entity is to be respected.
1) if you're editing an english node, newly added products also have "english" set as their language.
2) If you're using Entity Translation and adding a french translation for the node, then the product values should be saved under "fr" as well.
(Assuming ET is enabled for both entity types).

Fixed #1 in #1558632: Pass correct langcode to field_attach_form, newly created entities..
That's what the patches in the issue so far tried to accomplish.

#2 is going to be more tricky because ET doesn't support multiple translation handlers on the same form right now (and we need one for the parent entity one for the inline entity). Opened #1865244: Allow multiple translation handlers on the same form in the ET issue queue to get feedback on further steps.

Retitling issue for clarity.

bojanz’s picture

Issue summary: View changes

Updated summary.

plach’s picture

Status: Active » Needs review
14.23 KB

I spent the last days working on the integration between ET and IEF: the attached patch is the result and relies on #1865244-3: Allow multiple translation handlers on the same form. I tested it only with the single-entity widget because this is my need currently, hopefully @bojanz et al. can help bringing this forward.

Edit: To make titles work correctly you need also the latest Title dev.

bojanz’s picture

I am devoting my day tomorrow to testing and completing this.

Please buy plach a beer when you see him. He certainly deserves a case or two :)

plach’s picture


malberts’s picture

@@ -760,16 +806,25 @@ function inline_entity_form_entity_form($controller, $entity_form, &$form_state)
   $labels = $controller->labels();
   // Build a deta suffix that's appended to button #name keys for uniqueness.
   $delta = $entity_form['#ief_id'];
+  $form_settings = $form_state['inline_entity_form'][$entity_form['#ief_id']]['form settings'];

I get a notice related to that:

Notice: Undefined index: form settings en inline_entity_form_entity_form() (línea 809 de [...]/inline_entity_form/inline_entity_form.module).

Here's what I did:
Updated to latest dev and applied the patch for entity_translation.
Updated to latest dev and applied the patch for inline_entity_form.
Updated to latest dev for title.
Updated and flushed.

Then I edited a node with a multiple-entity Commerce Product reference field. The node and the referenced entities are set as translatable by Entity Translation. The entityreference field is not translatable. The node has been translated into English and Spanish with Entity Translation. Some of the referenced products have also been translated previously using the product entity editing page and some are untranslated (but prior to these patches).

I viewed the node in English, then switched the current language to Spanish and edited it. It seems like once I've edited one of the untranslated referenced entities it shows that warning. I'm not sure if this behaviour is accurate or just coincidence.

Is there something I should dpm() for debugging purposes here?

plach’s picture

The patch supports only the single-entity widget, @bojanz may be working on improving it.

plach’s picture


Any news?

candelas’s picture

any news?

andrea.brogi’s picture

Do you tink that this post can be related to this issue?


candelas’s picture

i have a commerce kickstart installation and would like to help trying this patch, but i am not sure what to try. for what i understand, it will work only on products that have only one variation. am i right?
sorry for my bad english :)

plach’s picture

Yep, the patch currently provides ET integration only for single-entity widgets.

abenil’s picture

For everyone who is looking for alternatives to this patch:
The Rules module, get Language from Node and set it in a loop to your child nodes. As event choose "Before saving an entity". Worked like a charm.

MXT’s picture

Priority: Normal » Major

in #21 Bojanz wrote:

I am devoting my day tomorrow to testing and completing this.

Please buy plach a beer when you see him. He certainly deserves a case or two :)

That "tomorrow" was never arrived, after almost 5 months...

@Bojanz: do you have any news on this?

Thank you

plach’s picture

14.3 KB

Rerolled aginst the latest dev, it would be good to have some feedback sooner or later :)

candelas’s picture

in commerce kickstart 7.x-2.9 with last entity translation dev and inline entity translation dev. the site has spanish as a default language and the english as a second language. the products were created in english and then translated. the only field on the variation that has to be translated is the title (using the module).

if i apply the #33 patch and try to add a product, i get this error:

Fatal error: Call to undefined method EntityTranslationNodeHandler::addChild() in /xxx/profiles/commerce_kickstart/modules/contrib/inline_entity_form/inline_entity_form.module on line 904

i tried with the product field Product variations (Product reference, Inline entity form, Single value) as a translatable or not and in both i get the error.

if i dont apply the patch and work with the entity translation dev the variations title gets translated and saved in the right place, but the products get it wrong. this happens when you create a product o when you edit a product.

i notice a change from before that maybe has relation. before if i was on spanish and edit the product, i will go to the spanish translation. if i was in english i will get the edit form for the product (english was the language that it was created). now, if i am in the spanish language and edit, i will get the english edit node.

the problem is that if i edit the product title it gets the same language in the product for both languages, though it gets well saved in the variations. i can notice already when i click edit in one language and go to the other, the title is wrong in the form taking the title from the interface. strange because the url alias is well created.

i have cleared all the caches by truncating directly in the database and still keep with the problem.

thanks for your excellent work (here and 8) and i hope this gets resolved soon to be able to have commerce kickstart to be multilingual on 7.

candelas’s picture

i just realize that i had not the entity translation dev so i restore backup, clear cache and try to add a product from the english interface. i made the entity reference field translatable and add a product. when i go to translate i shows all the fields and not only the ones that i want to translate. specially sku. so its not working on my installation. thanks anyway :)

murfi’s picture

this is an attempt to modify the patch at #33 to support multiple values;
it seems to work, but i'm not familiar with the code so my solutions are more or less ad-hoc; please help if you can; thank you

1. a correction to the above patch - in inline_entity_form.module, function inline_entity_form_entity_form:
$form_state['inline_entity_form'][$entity_form['#ief_id']]['form settings'] is not available on edit so i moved it back on the 'add' branch as in dev; to get the bundle name needed for the translation handler i used entity_extract_ids, the entity being available at that point;

2. in inline_entity_form.module, function inline_entity_form_add_child_translation_handler:
- set manually the source language on the handler if it is not set and parent language is not equal to parent original language (on multiple values, translate node -> edit variant, the source language is not set on the handler)

3. in includes/entity.inline_entity_form.inc, function entityFormSubmit:
- set manually the form language on the handler (on single value it is set; on multiple values, new node -> add variant, $entity_form['#parent_language'] is 'und' at ajax variant submit time; on edit or translate node, $entity_form['#parent_language'] is available)

Pere Orga’s picture

Status: Needs review » Needs work
3.33 KB

Using dev versions of everything, patch #36 did solve the problem when editing existing (parent) content, but not when adding new content. I'm attaching a screenshot of the javascript error I get.

I did not test patch #33

netdreamer’s picture

Another alternative approach while this one is definitely fixed:
A post from Kristofer Tengström with a workaround based on hook_entity_presave() (to be put in a custom module): http://storleden.se/blogg/how-translate-products-drupal-commerce

netdreamer’s picture

Issue summary: View changes

And again.

rsmylski’s picture

Re-rolled the patch from 36 against latest dev.

I also made a small tweak to things as well. I added some code from entity_translation_field_attach_form() to entityFormSharedElements() which sets default values when adding a translation.

My apologies for the mix up with the patch comment mis-match. This is my first post of a patch using the new format.

rsmylski’s picture

Issue summary: View changes
17.73 KB
rsmylski’s picture

Revised latest patch to fix a few php warnings related to getting the entity bundle needed in inline_entity_form_entity_form().

klonos’s picture

MXT’s picture

Status: Needs work » Needs review

For #41

JeroenT’s picture

I installed patch #41, created 2 translatable nodes with some fields on it and then I get the following Ajax error:

Fatal error: Call to undefined method EntityTranslationNodeHandler::addChild() in /home/sc3169cb04bf3c6e/www/sites/default/modules/inline_entity_form/inline_entity_form.module on line 989

frikovc’s picture

I applied #41 to latest dev and when creating new node via inline_entity_form with multiple value widget I get following error:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /en/system/ajax
StatusText: Internal Server Error

rsmylski’s picture

Re-rolled patch against latest dev release.

marcusx’s picture

I added a patch to #2028711: Field language is not correctly set on new nodes Comment to fix a problem with new (unsaved) parent entities. Maybe this needs to be merged with this patch or committed together. Please have a look.

garphy’s picture

-    $form_settings = $form_state['inline_entity_form'][$entity_form['#ief_id']]['form settings'];
-    $entity_form['#entity'] = inline_entity_form_create_entity($entity_form['#entity_type'], $form_settings['bundle'], $entity_form['#parent_language']);
+    $bundle = reset($form_state['inline_entity_form'][$entity_form['#ief_id']]['settings']['bundles']);
+    $entity_form['#entity'] = inline_entity_form_create_entity($entity_form['#entity_type'], $bundle, $entity_form['#parent_language']);

I don't understand why this change is needed. Moreover, it breaks the ability to add new entities when more than one bundle is available, because of the reset().
Reverting this change makes the "Add" work again.

BTW, the entity_translation integration is working fine here with my custom (ECK) entity hierarchy.

stopshinal’s picture

Hey Friends- great work!

Using latest dev version and patch from #46 I can create a node with a inline entity field and create more nodes that inherent the parent language. No problem.

However when I attempt to translate this node, and click "edit" on the inline entity nodes, I end up modifying the same node. As in - there is no notion of translating the inline entity field node even though I am translating the 'parent' node.

Not that it should, but the language selector dropdown does not show up in the inline entity field either.

Is this functionality currently available by design? Or is this beyond the scope of the current patch/module.

alm’s picture

Hi, I have the same problem.
#46 solved almost everything, except the issue reported in #49
For now my quick dirty fix for my specific case (node with field "field_product" of type "Product reference") is to add this hook:

function hook_entity_presave($entity, $type) {  
  if ($type === 'node' && isset($entity->field_product) && isset($entity->field_product[LANGUAGE_NONE]) && $entity->language != LANGUAGE_NONE) {
    $entity->field_product[$entity->language] = $entity->field_product[LANGUAGE_NONE];
    $entity->field_product[LANGUAGE_NONE] = array();

I have not had time yet to test extensively or to a better a fix, but seems to work.

jantoine’s picture

@stopshinal, @alm,

You are most likely seeing this issue because Entity Translation has not been enabled for the product variation type being referenced. If you have Commerce Backoffice installed (included with Commerce Kickstart), see #2203317: Support Entity Translation for Commerce Product.

After enabling Entity Translation for the product variation types being referenced, I was seeing the same error reported in #45 until I updated the the latest Entity Translation dev release.

jchengfas’s picture

I installed the dev version of inline entity translation and applied the patch in #46, but I still get the error "Call to undefined method EntityTranslationNodeHandler::addChild() in ...sites/all/modules/inline_entity_form/inline_entity_form.module on line 997". I tried the patch in #48, and that didn't make any difference. Does anyone know what the problem is? Many thanks!

trim108’s picture


You need to install dev version of entity_translation and clear all caches.

The patch in #46 works fine but there ajax error with Add button. So we need to create node firstly and then Add button works and we can create referenced node. And also translations should be disabled for the field.

garphy’s picture

Deletion of referenced entities when parent entity is deleted is broken (I think it arise when you have multiple ER field on the same bundle and those fields don't target the same entity_type).

I think this logic in the patch is wrong :

diff --git a/inline_entity_form.module b/inline_entity_form.module
index 6c6228f..ba8219a 100644
--- a/inline_entity_form.module
+++ b/inline_entity_form.module
@@ -191,6 +191,46 @@ function inline_entity_form_entity_delete($entity, $type) {
+ * Implements hook_entity_translation_delete().
+ *
+ * Deletes a translation of the referenced entity.
+ */
+function inline_entity_form_entity_translation_delete($entity_type, $entity, $langcode) {
+  list(,, $bundle) = entity_extract_ids($entity_type, $entity);
+  foreach (field_info_instances($entity_type, $bundle) as $field_name => $instance) {
+    if (strpos($instance['widget']['type'], 'inline_entity_form') === 0) {
+      $controller = inline_entity_form_get_controller($instance);
+      // The controller specified that referenced entities should be deleted.
+      if ($controller && $controller->getSetting('delete_references')) {
+        $items = field_get_items($entity_type, $entity, $field_name, $langcode);
+        if ($items) {
+          $field = field_info_field($field_name);
+          $ief_settings = inline_entity_form_settings($field, $instance);
+          $ids = array();
+          foreach ($items as $item) {
+            $ids[] = $item[$ief_settings['column']];
+          }
+          $ref_entity_type = $ief_settings['entity_type'];
+          $context = array(
+            'parent_entity_type' => $entity_type,
+            'parent_entity' => $entity,
+          );
+          foreach (entity_load($ref_entity_type, $ids) as $id => $entity) {
+            $handler = entity_translation_get_handler($ref_entity_type, $entity);
+            $handler->removeTranslation($langcode);
+            $controller->save($entity, $context);
+          }
+        }
+      }
+    }
+  }

The iteration over referenced child entities overwrite the $entity variable in the function scope. As a result, the $items retrieval through field_get_items() and the $context initialization (parent ref) goes crazy when entering the next loop step.

Using a $ref_entity instead of $entity in the nested loop solves the issue for me.
I'm on my way to produce a patch for this but if somebody have thought on this before...

garphy’s picture

17.25 KB
841 bytes
paulihuhtiniemi’s picture

I tested the latest patch, I'm also getting an AJAX error as mentioned in comment #53

EDIT: actually when using latest DEV version of entity_translation, I don't get any javascript errors. But product entities created inline still get language und instead of language of parent node.

axe312’s picture

Hey there,

we use this patch to create translatable entities build with eck referenced within an node page. For several times we ran into problems setting this environment up. Here is a short description how to to that:

Patch it:

Configure it:

  • Make sure your entity reference field is NOT translatable.
  • Enable the language property for your eck entity -> /admin/structure/entity-type/[YOUR_ENTITY_TYPE]/edit
  • Enable entity translation for your entity -> /admin/config/regional/entity_translation

A lot of stuff to do, but it is working for us in several projects :)

Greetings from Berlin, Germany

yannickoo’s picture

Nice summary Ben, thanks! Could you please link specific patches instead of just the issues? :)

orbistertius’s picture

I am using IEF in a proyect with 2 differnet use cases. There is the product reference without details about the language y a content type with child nodes where tanslation is important. When I use the last patch I get the line items of the product reference without titles, same in the widget form table. Need to say that I made some changes in the line-item view and have an alter for the widget table to show other fields. Is there someone out there with a similar problem?

yannickoo’s picture

We noticed that the field language is not set for referenced entities within new nodes.

When you are trying to debugging this take a look at the entityFormSubmit method. On line 393 the parent language is grabbed but I think here is some wrong logic.

Trying to work on this later :/

marcusx’s picture

@yannickoo I tried to debug this some months ago. If you try to improve this have a look at the node module. The main reason for this problem is as far as I was looking through - the crazy logic that sets a node language during node_save. But IEF would need it from the incomplete node object in the form. I had no idea how we can grab this data and avoid that crap is saved if someone is changing the language in the dropdown after the IEF entity has already beens saved through AJAX.

We tried to fix this by prepopulating the language in the callback of node/add and finally ended up to deactivate IEF until the node is saved. But I would still say the things can become messy if the language drop-down on the node form is enabled and the user changes the language after creating the inline entity. It made things better in most cases but still not bullet proof.

yannickoo’s picture

Thank you Marcus for the input. Here is a code snippet (based on a gist Marcus sent me) which helps you to bypass the issue with the field language of the fields in the referenced entity:

 * Implements hook_form_alter().
function MYMODULE_form_alter(&$form, &$form_state, $form_id) {
  $content_type = 'basic_page';
  $reference_field = 'field_references';

  if ($form_id == $content_type . '_node_form') {
    if (!isset($form['#node']->nid)) {
      $form[$reference_field][LANGUAGE_NONE]['actions']['#access'] = FALSE;
      $form[$reference_field][LANGUAGE_NONE][] = array(
        '#prefix' => '<div class="messages warning">',
        '#markup' => t('You need to save this page first in order to add entities.'),
        '#suffix' => '</div>',

This is how it looks like:

gge’s picture


The latest patch "entity-translations-1545896-55.patch" won't work with "inline_entity_form 7.x-1.x-dev". Can somebody please update it?

paravibe’s picture

Patch #55 works like a charm for me.
Thanks a lot!
I have made a new patch for the latest dev.

gge’s picture

Thank you for the patch. I think it's working great for me too.

gge’s picture

23.61 KB

I just realized that I'm getting a nasty ajax error when using an address field in a child node. The error pops up as soon as I want to select a country. When removing the patch (#64) the error will not show up anymore.


gge’s picture

I think the status of this issue should be changed to "Needs work".

axe312’s picture

@gge are you sure that this is related to this patch/issue? Does it only happen when the patch is applied?

gge’s picture

For me, this patch works as long as the Inline Entity Form does not contain an address field. If the address field is removed, there is no 503 error.

gge’s picture

I think my problem came from the fact that in my template.php, the code mentioned yannickoo #62, was wrong. Actually i used a different content type for testing and after that I forgot to modify $content_type and $reference_field.

When I changed the code in template.php the error disappeared.

However I still think there's still a problem. When the Inline Entity form is required, you can't save first the parent node, without having to create an Inline Entity Form item.

garphy’s picture

However I still think there's still a problem. When the Inline Entity form is required, you can't save first the parent node, without having to create an Inline Entity Form item.

Well, this is more a feature than a bug. If a field is required, then, you have to fill it. I don't think it's related to Inline Entity Form. You would have the same "issue" with the default Entity Reference Autocomplete form.

marabak’s picture

Rob C’s picture

Status: Needs review » Needs work

Patch in #72 needs work (see the info files, that needs to go).

kalinchernev’s picture

Tested patch #65. It sets the language of the child entity correctly.
However, connection is lost. Editing parent entity after save, child entity is not loaded in the parent one.

axe312’s picture

@kalinchernev: look at https://www.drupal.org/node/1545896#comment-9414387, this workaround should help.

minorOffense’s picture

As some info to help things along, applying the patch generates this warning:

Notice: Undefined index: name in EntityTranslationNodeHandler->entityFormSubmit() (line 95 of /var/www/html/drupal/profiles/spotlight_profile/modules/contrib/entity_translation/includes/translation.handler.node.inc).

Happens when adding a translatable child node from a parent node using inline entity form.

heathdutton’s picture

Just #65 without version specificity so that it can be applied to 7.x-1.x

This is still resulting in errors though for me, after applying, such as:

 Maximum function nesting level of '100' reached, aborting! in .../modules/contrib/entity_translation/includes/translation.handler.inc on line 510
heathdutton’s picture

ciss’s picture

@heathdutton: It's actually quite easy to hit the 100 mark for complex nested entities, in my experience. See if you still experience problems if you raise the limit to 200.

bojanz’s picture

+          if ($field['translatable']) {
+            $element = &$entity_form[$field_name];
+            $element['#entity_type'] = $entity_type;
+            $element['#entity'] = $entity_form['#entity'];
+            $element['#entity_id'] = $id;
+            $element['#field_name'] = $field_name;
+            $element['#source'] = $update_langcode ? $form_langcode : $source;
+            $element['#previous'] = NULL;
+            $element['#form_parents'] = $entity_form['#parents'];

#entity_type and #entity are already set and aren't changed here, so those two assignments can be removed?
Also, who do we need #entity_id if we have #entity?

+    // Update the entity language using the parent entity submitted value.
+    if (!empty($info['entity keys']['language'])) {
+      $parent_info = entity_get_info($entity_form['#parent_entity_type']);
+      if (isset($parent_info['entity keys']['language']) && isset($form_state['values'][$parent_info['entity keys']['language']])) {
+        $entity->{$info['entity keys']['language']} = $form_state['values'][$parent_info['entity keys']['language']];
+        $handler = module_invoke('entity_translation', 'get_handler', $this->entityType, $entity);
+        $lang = $handler->getFormLanguage();
+        if ($lang == 'und') {
+          if ($entity_form['#parent_language'] != 'und') {
+            $handler->setFormLanguage($entity_form['#parent_language']);
+          }
+          else {
+            $handler->setFormLanguage($form_state['values'][$parent_info['entity keys']['language']]);
+          }
+        }
+      }
+    }

This assumes that the parent entity is on the top level, so it won't work for nested inline entity forms.
So we at least need to take #parents into account, if we need to go into $form_state directly.

This code is complex and I barely understand it, so we'll need to add a bunch of tests if we were to commit it.
Otherwise I'm afraid we'll just create 20 followup issues from people.

deelite’s picture

Sorry, I don't get it. I create nodes in German and translate them into English.

I have a node type (1) which references another node type (2). I think, 2 ways to translate the referenced node type (2).

1. The inline translation when translating the parent node type (1)
2. The translation of every single referenced node (2) and new referencing within the parent node (1).

Way 1 doesn't work. When translating the parent node (1) I only can edit the refered node (2). There's no way to create a translation for it.

Way 2 doesn't work. When translating the parent node (1) I only can reference to nodes (2) in German (the source language).

My questions:

1. Which releases of inline_entity_form and entity_translation should I use and which patches do I need to use?
2. Which way to translate my referenced entities can I go?

Sorry, but I'm trying to get that working since 2 days. But now I'm really confused.

minorOffense’s picture

If anyone who's been working on this issue or has a more in-depth knowledge of inline entity form is going to DrupalCon LA, I'll be there as well. Maybe we could meet up and hammer through this a bit. I have time / budget / technical skill to get this resolved but I'm a bit lost in what the patch doing.

Send me a message if anyone's interested.

MXT’s picture

I've applied patch in #77 and seems to work fine at 80%.

A issue I have is the same as described here:

When I created inline entities at the same time as the parent node, I've experienced the problem, that those entities get the wrong language code set (neutral). E.g. you create a new node in German, and while not having it saved to the database, you add one or more entities to the node. As the node doesn't exist at the time of saving the entities, they and especially the entity reference field values all get the 'und' language code. So, after creating the node, the node is having a different different language (german) than the entity reference field values (neutral), which is leading to the problematic situation, that you still can view the fields, but no longer edit them on the node edit form because they are no longer appearing there.


  1. #2028711: Field language is not correctly set on new nodes
  2. and my comment: https://www.drupal.org/node/2028711#comment-9891955

Another issue is the following:
If I create new "sub-nodes" within the "original source language" parent node form, the subnodes are saved with node->translations->original correctly set to the original source.
But if I create new "sub-nodes" within a translation of the parent node form, the subnodes are saved with node->translations->original setted to NULL (and this obviously generates issues with sub-nodes translations)

valthebald’s picture

mattew’s picture

For me #62 may be a good workaround. When initial node exists and has a language, all sub-entities created from it get the good language, even with two entity creation nested!

deelite’s picture

44.06 KB

One of our guys did some changes within the module to use it with i18n, based on dev version from 2015-02-26.

Wenn translating a parent node, for all referenced nodes a translation will be created and marked as 'translation of: ORIGINAL TITLE'. It depends node_clone for this functionality. In node_clone configuration 'Bypass confirmation' needs to be set.

In our case it works well in all cases of changing, deleting or re-referencing nodes. Also with nested references.

The update functionality is disabled for this module.

It's a HACK! Not a new version and not a patch.

Please use it on you own risk!

a.milkovsky’s picture

#77 works for me. All the patches before 77 didn't apply.

Issue1: The same as in #83
Issue2: Fields are not pre-populated from original language when I add a new translation.

a.milkovsky’s picture

Just re-roll of #77 with latest dev.

a.milkovsky’s picture

#83 is fixed by https://www.drupal.org/node/2028711#comment-10117384
Should we merge the two patches?

Still few things left here:
1. Fields are not pre-populated from original language when I add a new translation.
2. Things mentioned in https://www.drupal.org/node/1545896#comment-9766007

fago’s picture

+++ b/includes/entity.inline_entity_form.inc
@@ -272,10 +272,84 @@ class EntityInlineEntityFormController {
+          // If we are creating a new translation we have to change the form item
+          // language information from source to target language, this way the
+          // user can find the form items already populated with the source values
+          // while the field form element holds the correct language information.

Is this how entity translation usually works? I must say this sounds complex - why not just copy the field values being part of $entity to the new langcode and load the form as it would be a translation edit?

fago’s picture

ok, I took a look at this to make it basically work. I merged the latest patch from #2028711 as needed for this into this patch - hard enough to make it work as is.

So attached patch works for me when the parent entity language is not changing. It also renames the buttons when you are at a translation to make operations clear. It does not solve the problem of missing values when adding a translation though. Also "Edit" in case of a translation should be called "Add translation" still I htink.

fago’s picture

ok, added in the "Add translation" link also.

fago’s picture


FreekVR’s picture

I've tried the last patch on the latest IEF dev along with entity_translation enabled on both the host and child nodes, but getting ajax errors when creating a new "parent" node and immediately creating child nodes using IEF as well. When I first create the parent, then edit it again to create new children using IEF, it does work.

Was able to do some debugging. The issue is essentially an infinite loop being generated in entity_translation (\EntityTranslationDefaultHandler notifyChildren())

For some reason when creating a new node within a new node, the parent node (in my case "product_page") is listed as a child. Here's a dump showing the value of $this in that function (modded out non-relevant bits for readability)

EntityTranslationNodeHandler Object
    [entityType:protected] => node
    [entity:protected] => stdClass Object
            [uid] => 1
            [name] => root
            [type] => product_page
            [language] => und
            [title] => 
            [status] => 1
            [promote] => 0
            [sticky] => 0
            [created] => 1437121381
            [revision] => 
            [entity_translation_handler_id] => node-new-1
            [translations] => stdClass Object
                    [original] => 
                    [data] => Array


            [path] => Array
                    [pathauto] => 1


    [entityInfo:protected] => Array
            [efq bundle conditions] => 1
            [label] => Node
            [controller class] => NodeController
            [base table] => node
            [revision table] => node_revision
            [uri callback] => node_uri
            [fieldable] => 1
            [entity keys] => Array
                    [id] => nid
                    [revision] => vid
                    [bundle] => type
                    [label] => title
                    [language] => language
                    [uuid] => uuid
                    [revision uuid] => vuuid
                    [translations] => translations
            [translation] => Array
                    [entity_translation] => Array
                            [class] => EntityTranslationNodeHandler
                            [access callback] => entity_translation_node_tab_access
                            [access arguments] => Array
                                    [0] => 1

                            [bundle callback] => entity_translation_node_supported_type
                            [default settings] => Array
                                    [default_language] => und
                                    [hide_language_selector] => 

                            [path schemes] => Array
                                    [default] => Array
                                            [admin theme] => 1
                                            [path wildcard] => %node
                                            [edit tabs] => 1


                            [edit form] => node

                    [locale] => 1

            [static cache] => 1
            [field cache] => 1
            [load hook] => node_load
            [inline entity form] => Array
                    [controller] => NodeInlineEntityFormController

            [token type] => node
            [plural label] => Nodes
            [description] => Nodes represent the main site content items.
            [access callback] => entity_metadata_no_hook_node_access
            [creation callback] => entity_metadata_create_node
            [save callback] => node_save
            [deletion callback] => node_delete
            [revision deletion callback] => node_revision_delete
            [form callback] => entity_metadata_form_node
            [view callback] => entity_metadata_view_node
            [configuration] => 
            [uuid] => 1
            [language callback] => entity_translation_language
            [label callback] => title_entity_label

    [entityId:protected] => 
    [bundle:protected] => product_page
    [revisionable:protected] => 
    [children:protected] => Array
            [node-new-1] => EntityTranslationNodeHandler Object
    [revisionId] => 
maxplus’s picture


I'm testing patch #92 with current dev, and it works.

My use case:
A product display node with a product reference field, referencing multiple commerce products.
My product reference field itself is not translatable.
My product entity itself, is translatable using ET.
Using the Title module for my commerce product title, and this field is translatable.

There is one small error, but only for the admin-interface:
When I translate a commerce product using IEF with the new "Add translation" button: the variation title displayed in the IEF table is reverted back to the source language
=> only after saving the display node and edit the node again, the IEF table shows the correct translated product title.

Drupal 7.38
Entity Translation 7.x-1.0-beta4
Title 7.x-1.0-alpha7

sylus’s picture

Just thought I would chime in too as was using an earlier patch from this queue #62 and inline entity was working but only for a single language (one on creation). With the patch from #92 it now works for both languages and I really like the improvements fago made to the translation buttons and great that only have this single patch to apply to get this functionality to work on latest inline_entity_form dev. Thanks fago for all of your work!

My current workflow that has succeeded:

1) Content Type 'Basic Page' that is using Entity Translation for 'EN', and 'FR' and title module.
2) Content Type 'Inline Entity' that is using Entity Translation for 'EN' and 'FR' and title module.
3) Basic Page had an entity reference field with inline entity form widget that is not translated and selecting only node of 'inline entity' bundle.
4) Created content in Basic Page in English and filled out inline entity form (add node) title field + body.
5) Translated Basic Page content and filled out inline entity form (add translation) title field + body.
6) Verified both Basic Page content and Inline Entity content were as expected in English + French.


Entity Translation 7.x-1.0-beta4 (with patch from #2166157: entity translation handler id for new entities not unique enough - can cause infinite/circular child reference)
Title 7.x-1.0-alpha7
Inline Entity Form (dev) + Patch from #92

I did have the ajax issue when trying to use inline entity form without saving parent node first. I leveraged the following code to alert the user that the node needs to be saved first before using inline entity form field.

function example_form_alter(&$form, &$form_state, $form_id) {
  $content_type = 'bundle_name';
  $reference_field = 'field_name';

  if ($form_id == $content_type . '_node_form') {
    if (!isset($form['#node']->nid)) {
      $form[$reference_field][LANGUAGE_NONE]['actions']['#access'] = FALSE;
      $form[$reference_field][LANGUAGE_NONE][] = array(
        '#prefix' => '<div class="messages warning">',
        '#markup' => t('You need to save this page first in order to add entities.'),
        '#suffix' => '</div>',
drupalninja99’s picture

The issue I am having is that if the 'add new' button just spins forever on a new node. If I save the node the 'add new' button works.

Here are the errors I received:
Notice: Undefined index: field in field_widget_field() (line 578 of ../modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of ../modules/field/field.form.inc).
Notice: Undefined index: #ajax in ajax_form_callback() (line 391 of ../docroot/includes/ajax.inc).
drupalninja99’s picture

One issue is this line: in the inline_entity_form.module file:
if (!empty($form_state['entity_translation']['is_translation']) && $langcode != LANGUAGE_NONE) {

I never see $form_state['entity_translation'] populated on new nodes or existing ones.I have been able to isolate the problem to this code block:

if (!isset($element['#entity']->$parent_entity_info['entity keys']['id']) && isset($form_state['complete form']['language'])) {
    $parent_langcode = isset($form_state['complete form']['language']['#value']) ? $form_state['complete form']['language']['#value'] : $form_state['complete form']['language']['#default_value'];
    $parent_is_translation = FALSE;
  else {
    // Get the langcode of the parent entity.
    $parent_langcode = entity_language($element['#entity_type'], $element['#entity']);
    $handler = entity_translation_get_handler($element['#entity_type'], $element['#entity']);
    $translations = $handler->getTranslations();
    $parent_is_translation = isset($translations->original) && $parent_langcode != $translations->original;

This was part of the patch from https://www.drupal.org/files/issues/d7_entity_translation_0.patch that modified the inline_entity_form_field_widget_form() function. It looks like it is trying to derive the translation of the parent node but it fails somehow on new nodes.

fago’s picture

Figured that
- the validation handler from Entity translation was missing, added that
- problems with missing default values are due to #2550809: Inline entity form integration misses parent entityForm() method with fieldable panels pane, patch over there fixes the problem

Also improved method naming a bit. I did not address the reported problems that occur when embedding nodes in nodes, thus leaving issue state at needs work.

hnutu’s picture

Took the latest patch from #99 and applied some line number changes to fit for IEF Version 7.16.

Because there was no code matching for 'clone', I removed this part.

Additionally I added some lines to use the autogenerate title function for commerce products.

Used system:
Drupal 7.39
Module Title 7.x-1.0-alpha7

maxplus’s picture


I'm using the patched version of #100 or #99 and I have the same issue as #97: the 'add new' button just spins forever on a new node. If I save the node the 'add new' button works.

Is this solved in #99 or #100?

I'm not using fieldable panel panes.


das-peter’s picture

I stumbled over a problem when using the title module with commerce products.
When you use inline edit to adjust the title of a product variation that's attached to the product display node and just save the node form (without using the inline-entity-form submit button first) all works well.
However, if you hit the inline-entity-form submit button ("Update variation") first the title module will fail to sync the correct title values.
I tracked the issue down to a missing entity form language handling for the later case. While the entity form language handling is done when using the inline-entity-form submit button, it isn't repeated on the actual node submit.
But as of that node submit the entity translation handler is rebuild and we need to re-do the handling.
The attached patch adds such a handling to inline_entity_form_field_attach_submit() right before the inline entity form controller is used to save the entity.
I did just limited tests, but the tests made look promising.

jespermb’s picture

I have been testing this patch and I am experiencing some issues with it. I am using entity translation, eck, title_field and inline entity form.
My work flow is:
1. Add new node
2. Enter title, body and select a language
3. Click Add related content (inline entity form)
- My language is preselected (nice!)
- Enter information
- Submit
- Related content is handled as expected
4. Click save
5. Upon save the data in the title and body are empty

After some investigations it seems the body and title are given the new language but the values from 'und' are not transferred to the new entry.
I am trying to figure this out, but I thought I would as if anyone else has experienced this?

mpp’s picture

Hi jesperjb, we encountered a similar issue with IEF & ET - not when creating a new node but when creating a translation we loose some of the existing multiple field data (see https://www.drupal.org/node/2339315 & https://www.drupal.org/node/2411971, there's a scenario here).

IEF is great but until we solve this issue it's not working great with ET. I'd like to help solve this but can someone point me out to some documentation how it is supposed to work or explain the logic chosen to solve this scenario:
- create node
- select language (e.g. english)
- add IEF entries (you need the language here, but it can still change..)
- change language on node (e.g. dutch, what should happen to the IEF data already created in english?)
- save

axe312’s picture

Issue tags: +Needs tests

I just wanna point out, that we need tests to clarify if this patch is working smoothly. It is a very complex implementation and almost impossible to test manually.

A lot of people rely on this module and bojanz is not going to merge anything which adds features without new tests.

There are many people here in the issue queue looking for help, maybe someone can take the time and money to create tests, I see a lot of big projects relying on these patches.

Also the work on the d8 version is going on very quickly, maybe somebody wants to help overthere, translation should be way easier over there.

rodrigoaguilera’s picture

I'm experiencing the errors on #103
and also I cannot add entities to the entityreference field from a translation form, only from the origin translation.

EclipseGc’s picture

Internal to Acquia, we're using Paragraphs some. I personally prefer IEF and have demoed that solution a few times, however it's interesting to note that this same error seems to rear its head in both IEF and Paragraphs. That made me suspicious of entity_translation, so I spent some time debugging and found: #2651050: entity_translation_prepare_element() needlessly clones $form_state.

Maybe that could help limit the scope of what's being suggested here?


aarnau’s picture

Took the latest patch from #102 I've resoved #103 issue adding a simple check in this line:

+ if (module_invoke('entity_translation', 'enabled', $entity_form['#entity_type'], $bundle) && $entity_form['#parent_entity']->translations->original != null) {

Sebastien @Actualys’s picture

Status: Needs work » Needs review

The last submitted patch, 48: entity-translations-1545896-48.patch, failed testing.

The last submitted patch, 55: entity-translations-1545896-55.patch, failed testing.

The last submitted patch, 64: inline_entity_form-entity_translations-1545896-64.patch, failed testing.

The last submitted patch, 72: inline_entity_form-entity_translations-1545896-65.patch, failed testing.

The last submitted patch, 88: inline_entity_form-entity_translations-1545896-88.patch, failed testing.

The last submitted patch, 91: d7_entity_translation.patch, failed testing.

The last submitted patch, 92: d7_entity_translation.patch, failed testing.

The last submitted patch, 99: d7_ief_et.patch, failed testing.

The last submitted patch, 100: d7_ief_et_autogenerate_title.patch, failed testing.

The last submitted patch, 102: inline_entity_form-entity_translation-1545896-102.patch, failed testing.

The last submitted patch, 102: interdiff-1545896-99-102-do-not-test.diff, failed testing.

Status: Needs review » Needs work

The last submitted patch, 108: inline_entity_form-entity_translation-1545896-110.patch, failed testing.

candelas’s picture

It would be nice that now that plach is working on the Plan for Entity Translation 7.x-1.0 release this would be solved.. I am sad that I don't have your knowledge to collaborate. Thanks for all your work :)

Musa.thomas’s picture

Heloo seems the last patch #108 missing one line to fix translatable field :
in .module in inline_entity_form_field_attach_submit after test parent handler.

      if($langcode!=$entity_form_language && $entity_form_language==$parent_entity_language) {
Musa.thomas’s picture

Musa.thomas’s picture

sorry :( wrong issue number in patch name

candelas’s picture

Status: Needs work » Needs review

I change to needs review for test. Thanks @Emerya.thomas , I will try to review the weekend.

The last submitted patch, 123: inline_entity_form_d7_entity_translation-2028711.patch, failed testing.

The last submitted patch, 124: inline_entity_form_d7_entity_translation-2028711.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 125: inline_entity_form_d7_entity_translation-1545896.patch, failed testing.

candelas’s picture

Please, correct me if what I say I will test is not complete :)

For what I understand, there are 3 uses-cases:

  • When there is only one language and it is not English
  • When there is a translation to several languages and all fields are translated
  • When there is a translation (one or more) and only some fields are translated (my case)

Then there are 2 cases for the widget type:

  • Inline entity form - Multiple values (my case)
  • Inline entity form - Single value (my case)

While this issue is solved, I have solved the problem using Rules to assign the correct language. My site is a Commerce Kickstart with 3 languages, and I don't make the field product reference translatable because then I have to translate all fields. With 'Inline entity form - Multiple values', I have a field for translating the title (my only need to translate) for each language on the variation.

I will test with Commerce Kickstart 7.x-2.37 and I will use the Inline Entity Form dev version (they use 7.x-1.6, not the actual 7.x-1.8) and the Entity Translation dev.

Any input is welcome :)

candelas’s picture

Musa.thomas’s picture

For my use case:
Simple node with entity references field with IEF multiple values. This field is tranlatable and the entities too (parent and child).
IEF and entity traslation are used

bojanz’s picture

Note that the D8 version of IEF got content translation integration recently, along with a matching test (TranslationTest). Both the test and the implementation could be used for inspiration.

candelas’s picture

@bojanz, thanks for your attention... I am a student on programming... I can test and debug 4 or 5 lines, but I am not jet a programmer... I can offer to test all patches that you all make (I learn a lot with this) for the cases that I mention or you say. Maybe we can make different issues and this to be the parent... or as you tell :) I understand that after programming, documenting and testing is tedious, so I can give a hand.

@Emerya.thomas, in your use-case all the fields in IEF are translatable? Is your patch for this use case?

Also to say that plach has work a lot and there are few issues to solve for the ET 7.x-1.0 and has a group of crazy_ukranians that maybe (next weeks they test) became the co-maintainers. So let's push this and Commerce/CK will solve the main blocker to be fully multilingual! ;)

candelas’s picture

The issue that bojanz mentions #2494959: Add translation integration

Musa.thomas’s picture

Hey seems the my last patch is wrong, you made patch wiith the download version and not with the repository version. So there are some reject in .info. I just delete this part of the patch

garphy’s picture

For information, on latest IEF release (1.8), when this patch is applied, any use of the IEF widget results in the ER field to become empty on save.
Not sure why yet but as there were massive changes since it was rolled out it may need some rework.

garphy’s picture

there were massive changes

At least, lots of commits...

garphy’s picture

Well, after some deeper digging :
- patch from #108 seems to work correctly
- patch from #136 makes IEF clears every value of the ER field whenever I edit an already referenced entity or try to add a new one to the list : the referenced entity is created/updated by the ER field values are cleared.

garphy’s picture

Rerolled #108 which actually wasn't applying correctly.

(drush make was happily appling #108 directly on 1.8 but git would not...)

Status: Needs review » Needs work

The last submitted patch, 140: inline_entity_form-add_entity_translation-1545896-140.patch, failed testing.

minorOffense’s picture

Testing the patch from 140 it appears that when creating new content, the entity doesn't get the language from the newly created entity. Only gest LANGUAGE_NONE.

But adding translations to the content, the referenced entity does get the right language.

So you end up with:

English Side Node -> LANGUAGE_NONE entity
French Side of Node -> FRENCH side of entity

Language neutral is not an allowed option in the entity translation settings. The entity ref field is language neutral. Node is translated of course with entity translation.

minorOffense’s picture

If you go back and edit the referenced entity after saving the node, the fields then pick up the current language properly.

adinac’s picture

I applied the patch from #140 but it did not work correctly because it seems there was a problem with the $element['#entity']->$parent_entity_info['entity keys']['id'] expression and php 7. So I changed it into $element['#entity']->{$parent_entity_info['entity keys']['id']}.

betoscopio’s picture

Tested patch from #144 and worked well for me on IEF 1.8 and latest dev. Using PHP5.5
Tested on a node translatable node with a entityreference-1.2 non translated field.
When a related entity is added, does it in the same language of the main node, even in new nodes.
Is possible to translate the related entities from a translated version of the original node.
Is possible to clone related entities (does it with its original translation if exists).
Is not possible create new related entities from the translated version of the node, which I can without the patch. I guess this is designed as a feature, but I wasn't expecting that behavior.

For me case is working well, so what else we need to commit this? I guess make all tests pass and write some other cases maybe?

Thanks all for the great work.

plach’s picture

Status: Needs work » Needs review

Let's give the latest patch a test...

Status: Needs review » Needs work

The last submitted patch, 144: inline_entity_form-add_entity_translation-1545896-144.patch, failed testing.

ivanaldavert’s picture

+1 #145, I can't create new entities from translated nodes. In addition, when I translate a node in a third language or more, the translated entities appears blanks on edit form, not on view, maybe that's not dramatically but can be patched?

Thanks for all the great work guys! This saved me a lot of time :)

GoZ’s picture

+++ b/includes/commerce_product.inline_entity_form.inc
@@ -247,6 +245,10 @@ class CommerceProductInlineEntityFormController extends EntityInlineEntityFormCo
+    // Ensure our fieldsets are not hidden by the field translation handler.
+    $entity_form['product_image']['#access'] = TRUE;
+    $entity_form['product_details']['#access'] = TRUE;

Looks like this piece of code is not generic but is from a project.
It appears on #20 and has never been removed since.

Should be removed btw.

  1. +++ b/includes/entity.inline_entity_form.inc
    @@ -272,10 +272,83 @@ class EntityInlineEntityFormController {
    +      // that won't get run because $form_state['rebuild'] is TRUE for all IEF forms.

    Miss a new line before "forms" word to not exceed maximum number of letters on a line.

  2. +++ b/includes/entity.inline_entity_form.inc
    @@ -272,10 +272,83 @@ class EntityInlineEntityFormController {
    +          // If we are creating a new translation we have to change the form item
    +          // language information from source to target language, this way the
    +          // user can find the form items already populated with the source values
    +++ b/inline_entity_form.module
    @@ -904,6 +995,15 @@ function inline_entity_form_entity_form($controller, $entity_form, &$form_state)
    +  // Register a child entity translation handler to properly deal with the entity form language.

    Do not exceed the maximum number of letters by line

  3. +++ b/includes/entity.inline_entity_form.inc
    @@ -272,10 +272,83 @@ class EntityInlineEntityFormController {
    +          // language information from source to target language, this way the
    +            // If we are updating the form language we need to make sure that the
    +            // Swap default values during form processing to avoid recursion. We

    Do not exceed the maximum number of letters by line

xaa’s picture

patch with suggestions of #149

GoZ’s picture

#150 is an interdiff file with a patch name.

Please xaa, generate a patch with #144 and your updates + interdiff file.

I remove #150 from display to avoid mistakes.

xaa’s picture

here is. sry for the mess with the first patch

GoZ’s picture

Status: Needs work » Needs review

#152 looks good

gravisrs’s picture

#152 works perfectly

mrchristophy’s picture

I've been following this thread as I really want this to work. I've applied the patch and added some entities but when I go to translate the node the ief field is greyed out - any ideas? Sorry if this is a silly question:

matthiasm11’s picture

#152 works fine, thx.
@mrchristophy: my language switcher in the product display stays selectable.

mrchristophy’s picture

Sorry I got confused, nothing is greyed out (I was looking at the language switcher which is normal).

It's simply not displaying the form item at all, apart from the label. Is there a setting somewhere I have missed, or a permission?

Even if I make the field not translatable, it doesn't appear when trying to translate. What could it be?

Edit: This only happens with the 'Inline entity form - Multiple values' widget - the single value seems to work fine.

Screenshot attached below showing both original and translated admin screens.

mrchristophy’s picture

98.88 KB
shi99’s picture

#152 worked for me correctly when using Entity Translation with Node Types referencing Product Types.


GoZ’s picture

Status: Needs review » Reviewed & tested by the community
james.williams’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/inline_entity_form.module
@@ -406,11 +447,27 @@ function inline_entity_form_field_widget_form(&$form, &$form_state, $field, $ins
+    $handler = entity_translation_get_handler($element['#entity_type'], $element['#entity']);

This causes a fatal error on visiting the node add page for a node type that has an inline entity form widget on it, when the entity_translation project is not enabled. There's at least one other place ET functions are getting called (later in this same function), when it may not be available.

annared’s picture

i'm using inline entity translation with panel and entity translation.
i get this error when i try to add a translation:
EntityMalformedException: Missing bundle property on entity of type fieldable_panels_pane. in entity_extract_ids() (line 7929 of includes/common.inc).

badrange’s picture

Heads up; this thing just got committed to Entity Translation - it may affect this patch:

czigor’s picture

The only thing to do is to replace all (deprecated) ?etFormLanguage() calls with the new ?etActiveLanguage().

CoderBrandon’s picture

#152 works for me, but only for inline edit forms directly under the top level entity. For nested inline edit forms (ie: where the inline entity form itself has an inline entity form) the langcode gets set back to english.

Possibly related, but opening, cancelling, and re-opening an inline edit form resets the language back to english.

cavax’s picture

#152 seems not working.

The code above is not workign and it returns empty translations.

$translations = $handler->getTranslations();

The result is that the "add translation" button wont show up, any idea how to fix it?

Xenza’s picture

There is an issue with untranslatable entities that are using fields which are translatable:
Translatable should always store their data in the default language, not LANGUAGE_NONE as per: https://www.drupal.org/docs/7/api/field-api/language-support-for-entity-...

When submitting the entity form directly the result is as expected.
Entity is saved in LANGUAGE_NONE, field data is stored as 'en' (default language).

When saving through an IEF
Entity is saved as LANGUAGE_NONE and field language is changed from 'en' to LANGUAGE_NONE, making it invalid, causing the field to not be saved.

When handling field language changes we should also check for this state before changing the data as it is already correct.

alinaBasa’s picture

As per #164 comment replaced all (deprecated) getFormLanguage() calls with the new getActiveLanguage(), so that it will work with entity translation module version beta6

stefanos.petrakis’s picture

This patch works quite well at the moment, thanks to all!

And here is a review:

a) setFormLanguage() is deprecated and should be replaced by setActiveLanguage(). See http://cgit.drupalcode.org/entity_translation/tree/includes/translation....
b) entity_translation_get_handler() is called in various place without checking whether entity_translation is enabled, as mentioned in #161.
c) Tests are clearly very important, src/Tests/TranslationTest.php contains the D8 testing that was suggested as an inspiration/starting point in #133.


+++ b/includes/entity.inline_entity_form.inc
@@ -272,10 +272,85 @@ class EntityInlineEntityFormController {

+          if ($field['translatable']) {
+            $element = &$entity_form[$field_name];
+            $element['#entity_type'] = $entity_type;
+            $element['#entity'] = $entity_form['#entity'];
+            $element['#entity_id'] = $id;

#entity_type and #entity are already set and aren't changed here, so those two assignments can be removed?
Also, who do we need #entity_id if we have #entity?
(Reposted from #80)

+++ b/includes/entity.inline_entity_form.inc
@@ -318,8 +393,61 @@ class EntityInlineEntityFormController {
+    // Update the entity language using the parent entity submitted value.
+    if (!empty($info['entity keys']['language'])) {
+      $parent_info = entity_get_info($entity_form['#parent_entity_type']);  
+      if (isset($parent_info['entity keys']['language']) && isset($form_state['values'][$parent_info['entity keys']['language']])) {
+        $entity->{$info['entity keys']['language']} = $form_state['values'][$parent_info['entity keys']['language']];
+        $handler = module_invoke('entity_translation', 'get_handler', $this->entityType, $entity);
+        $lang = $handler->getActiveLanguage();
+        if ($lang == LANGUAGE_NONE) {
+          if ($entity_form['#parent_language'] != LANGUAGE_NONE) {
+            $handler->setFormLanguage($entity_form['#parent_language']);
+          }
+          else {
+            $handler->setFormLanguage($form_state['values'][$parent_info['entity keys']['language']]);
+          }
+        }
+      }
+    }

The outermost if condition should first check if entity_translation is enabled.

stefanos.petrakis’s picture

Here is a first draft of tests for this, the idea is:

a) Configure Entity translation with some common settings
b) Configure ief_test_multiple and ief_reference_type to be translatable using Entity translation
c) Add an extra reference field on ief_test_multiple that is translatable (field_multiple_nodes_translate)
d) Create a source node (of type ief_test_multiple) in English
e) Create a referenced node (of type ief_reference_type) via IEF using a non-translatable field (field_multiple_nodes)
f) Create a referenced node (of type ief_reference_type) via IEF using a translatable field (field_multiple_nodes_translate)
g) Add a translation to the source node in German
h) Add a translation to the referenced node of the non-translatable field (field_multiple_nodes)
i) Create a referenced node using the translatable field (field_multiple_nodes_translate); the new referenced node is attached to the translation of the source node
j) Verify that the display of the source node (node/%nid) and (de/node/%nid) loads the correct/translated content
k) Verify that the edit form of the source node (node/%nid/edit) and (de/node/%nid/edit) loads the correct/translated content

Attached are three patches:

  1. (inline_entity_form-add_entity_translation-1545896-170_enable_test_dependencies.patch): This one needs to be committed first, as it will allow the DrupalCI to download Entity Translation as a dependency when running tests.
  2. (inline_entity_form-add_entity_translation-1545896-170_tests.patch): These are the new tests; this patch should fail if tested. It can also be used as the interdiff between #168 and #170.
  3. (inline_entity_form-add_entity_translation-1545896-170.patch): This is the complete patch (#168) bundled together with the tests; this patch should succeed if tested
vitalie’s picture

Hi, this looks great (patches #168, #170). In my case, I have a multivalued reference field, that is itself translatable and so I would like two extra things:

1) Ability to remove an item when editing a translation of the parent entity. Patch #170 does not expose the Remove button anymore.

2) When a translation is being created (not edited) for the parent entity, I would like the reference field to be pre-populated with items from same field in the source language. This would be similar to how it is working for when the reference field is not translatable. Or course, Add translation and Remove (see point 1) buttons would be available for each item.

What do you think?

vitalie’s picture

Just found this comment in support of point 2 in #171 and since we aim to integrate with ET, I think this becomes even more relevant:

function entity_translation_prepare_element($element, &$form_state) {


  // If we are creating a new translation we have to change the form item
  // language information from source to target language, this way the user can
  // find the form items already populated with the source values while the
  // field form element holds the correct language information.

However, the above is not happening for IEF enabled, translatable fields. I've dug into this and there's a problem with the fact that IEF stores state related to the translatable field outside the field subtree in $form_state. In the same entity_translation function mentioned above the following lines of code won't copy the all that state over, it only copies state under the field subtree:

entity_translation_form_element_language_replace($element, $source, $langcode);
    entity_translation_form_element_state_replace($element, $source_form[$field_name], $field_name, $source_form_state, $form_state);

I've submitted a possible solution here: https://www.drupal.org/node/2339315#comment-12235439 #2339315: Source language prepopulated values should be also included in $form_state['field'].

Please help to push for that to be adopted by ET or suggest other avenues.

Another related issue: #2651050: entity_translation_prepare_element() needlessly clones $form_state

vitalie’s picture

I'd like also to discuss this part of patch #170:

+  // If the parent entity is new, the language is not yet set. Use the langcode
+  // from the parent form if existing in this case.
+  if (!isset($element['#entity']->{$parent_entity_info['entity keys']['id']}) && isset($form_state['complete form']['language'])) {
+    $parent_langcode = isset($form_state['complete form']['language']['#value']) ? $form_state['complete form']['language']['#value'] : $form_state['complete form']['language']['#default_value'];
+    $parent_is_translation = FALSE;
+  }
+  else {
+    // Get the langcode of the parent entity.
+    $parent_langcode = entity_language($element['#entity_type'], $element['#entity']);
+    $handler = entity_translation_get_handler($element['#entity_type'], $element['#entity']);
+    $translations = $handler->getTranslations();
+    $parent_is_translation = isset($translations->original) && $parent_langcode != $translations->original;
+  }

The line in the else clause:

$parent_langcode = entity_language($element['#entity_type'], $element['#entity']);

Behaves differently in an "ajax call cycle" compared to the initial form build cycle. This is because in the initial build cycle, the entity "active" language is being set/altered by entity_translation_add_page() or entity_translation_edit_page(), while in an "ajax cycle" those are bypassed. There's the entity_translation_entity_form_language_update() function which is called on element validate, but that happens too late.

How can we make sure $parent_lancode is same in all form cycles?

vitalie’s picture

Here's a patch that adds on patch in #170 and covers points in #171-173. The purpose of this effort is to make the integration work better with a translatable entityreference field.

Status: Needs review » Needs work
Xenza’s picture

While testing this with taxonomy terms there is a strange interaction with EntityTranslationDefaultHandler::entityFormSubmit().
Unlike node_form_submit which will take you to the node view page, taxonomy_form_term_submit does not add a re-direct when a term exists.
This then results in the user being redirected to the inline entity's edit form rather than the entity for which the save is being invoked upon.

maxplus’s picture

I'm testing patch from #174 and beside the FAILED .info-file patch, there is a small issue that in my setup a commerce product Title field is also hidden when the Entity Translation setting "Hide shared elements on translation forms" is checked.
=> the commerce product title field should be visible because it is a translatable field (title_field).

When I disable the option "Hide shared elements on translation forms", then everything works perfect and I can translate my commerce product title as it should

The error about the .info file is:

patching file inline_entity_form.info
Hunk #1 FAILED at 14.
1 out of 1 hunk FAILED -- saving rejects to file inline_entity_form.info.rej

Thanks again for making some progress in this issue

Rob C’s picture

@#177 maxplus

Did you try to patch on a git checkout or release ? Aka the version number in the info file will prolly make it fail. Remove the bit added by the packaging tool in the info file or do a git checkout of the repository and try again. Thanks.

vitalie’s picture

Ok, further, to make #174 or #170 work for ECK entities, another small patch to ECK is needed.

See: https://www.drupal.org/node/2915992

colinstillwell88’s picture

I just tried applying the patch from #174 against 1.8 (which is the head of the DEV branch) and it failed.

What version was the patch created against @stefanos.petrakis?

Skabbkladden’s picture

Replaces two calls to entity_translation_get_handler() with module_invoke('entity_translation', 'get_handler'), and checks if the handler is set before use.
Hopefully fixes #161.
I also added a patch against 1.8 release (with packaging information in the .info file) that should be usable in drush makefiles.

ciss’s picture

@Skabbkladden Why not simply call module_exists()? This feels like a hack.

Skabbkladden’s picture

No good reason I suppose. Just went with how it was already done elsewhere in the patch.
I agree that module_exists() is a better way, I'll revise my patch.

Skabbkladden’s picture

ciss’s picture

@Skabbkladden I'm not following this issue very closely, but that line containing module_invoke leaped out at me. Thanks for updating the patch!

@colinstillwell88 You can try my script at https://gist.github.com/mootari/fd1a2a3389bf914dcd2b to find the patch base. It served me well for field_collection's ET integration issue.

vensires’s picture

@Skabbkladden your #184 patch failed being completely applied to the .info file. Attaching .rej file. Other than I find it is working nice! Could you fix the conflict with the .info file and set this as "Needs review"?