the following issue may be related, but is in fact different to #1545896: Add Entity Translation integration

Before explaining the issue, here's my setup:
My node type is Entity Translation enabled and has a Entity Reference field with Inline Entity Form as widget, allowing an unlimited number of values. Due to the lacking ET support, I've set the field itself to be translatable, but not the entities. So that every node translation has its own set of inline entities.

Adding, editing and removing entities from existing nodes works perfectly, thus changing the node language afterwards is not recommendable, but that's no problem for me.

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

Members fund testing for the Drupal project. Drupal Association Learn more


ordermind’s picture

Priority: Major » Normal

I'm also experiencing this problem, and it makes translating product titles in Drupal Commerce a real hassle.

ordermind’s picture

Priority: Normal » Major
vmichnowicz’s picture

Priority: Normal » Major

I am having a similar issue as well with Inline Entity Form & Entity Translation. When I create a new node in English and then create multiple node references in the Inline Entity Form those new nodes do not get created in English. I have written a hook that seems to fix this issue.

function HOOK_inline_entity_form_entity_form_alter(&$entity_form, &$form_state) {
  global $language;
  $is_new = property_exists($entity_form['#entity'], 'is_new') && $entity_form['#entity']->is_new === true;

  if ($is_new === true) {
    $entity_form['#parent_language'] = $language->language;
    $entity_form['#entity']->language = $language->language;
    $form_state['build_info']['args'][0]->language = $language->language;
marcusx’s picture

I can confirm this problem.

I use eck patched with #1798646: Make ECK entities translatable (entity translation integration). and inline entity form patched with #1545896: Add Entity Translation integration if I create a new eck entity through ief and the parent entity node has not been saved the fields are saved as language neutral ("und").

My first attempt was to fix this during form submit. Around here (entity.inline_entity_form.inc - Line 402)

   if ($info['fieldable']) {
      // Retrieve the current entity form language.
      $langcode = entity_language($this->entityType, $entity);

      // Handle a possible language change: new language values are inserted,
      // previous ones are deleted.

But after deeper evaluation I think the problem arises already during form build. (inline_entity_form.module - inline_entity_form_field_widget_form() - Line 436)

entity_language() will return 'und' for new entities / nodes as the language for the node is collected from the form values in locale_field_entity_form_submit() So I get the language now from the complete form. Due to a missing is_new property at this place. I check against the existence of an entity id to decide if the parent is new in the attached patch. To avoid problems with the entity key I get the name for the parent id key from the entity info array for the parent beforehand.

    $parent_entity_info = entity_get_info($element['#entity_type']);

  // ...
  // snip....
  // ...

  // If the parent entity is new, the language is not yet set. Use the langcode
  // from the parent form in this case.
  if (!isset($element['#entity']->$parent_entity_info['entity keys']['id'])) {
    $parent_langcode = $form_state['complete form']['language']['#default_value'];
  } else {
    // Get the langcode of the parent entity.
    $parent_langcode = entity_language($element['#entity_type'], $element['#entity']);

Maybe someone knows a better solution. But so far I don't get any side effects. Please review.

ayalas’s picture

After applying this patch, when I enter the "Add product" page for the "Product Display" entity I get this error:

Notice: Undefined index: complete form in inline_entity_form_field_widget_form() (line 457 of /home/ubuntu/Web/commerce_kickstart/profiles/commerce_kickstart/modules/contrib/inline_entity_form/inline_entity_form.module).

The "complete form" index is not included in the $form_state array. This is line 457:

$parent_langcode = $form_state['complete form']['language']['#default_value'];

marcusx’s picture

Adding additional check if the complete form exists to avoid the notice mentioned in #5.

This will avoid the notice but not fix the problem. If we don't have the complete form we cannot have a look in the parent form. We need do find another way in this case to get the parent language. I have no commerce installation here right now for testing or looking into why there is no complete form maybe someone else with the above mentioned setup can look into this.

maxplus’s picture


I have tested #6 with my Commerce 7.x-1.8 installation and Inline Entity form 7.x-1.5
Until now I think it works but I will test it more.

Thanks already for the effort!

marcusx’s picture

I can confirm that #5 happens also in non commerce use cases and #6 is fixing that. The language is still saved correctly in my environment.

olofjohansson’s picture

I think there's a lot of different scenarios to keep in mind in order to solve this properly.

In my case, the language will always be set to "und", even with the patch from #6. The value for the language field is being set by the Locale module, in locale_form_node_form_alter(). Since this function executes at a later stage than the widget form, the proper value hasn't been set yet.

Why is the language being set at the stage when the form is being built? The user is able to change the language after the form has been loaded, so there is no way that this will work properly, or am I missing something? Since the inline entities aren't actually saved to the database until the user submits the main form, we shouldn't set the language until then. If we do, we can safely rely on the language for the main entity.

I haven't gone through the code deep enough in order to supply a patch for this though.

AdamGerthel’s picture

I did a quick test with Commerce Kickstart in an attempt to reproduce the issue we (me and ojohansson above) are having.

Our case:
I our case we have two enabled languages: English and Swedish. All product displays are in swedish (the site is not multilingual so no content is actually translated). When a new product display is created and a product is referenced, the language for that field value is stored as "sv" (swedish) when using the autocomplete widget. If inline entity form is used, the value is stored as "und", and the values are not displayed when the node is edited. Node language is swedish.

Commerce Kickstart:
I enabled Swedish and set is as default language. I added Inline Entity form. Any product display I created (no matter which widget I used) the field language was "und". Everything seems to work like it should. Node language is swedish.

So - what causes the language of the field to become "sv" in the first place? And how come the autocomplete widget and inline entity form behaves differently?

jonloh’s picture

Patched with #6 and it seems to be adding the language correctly the IEF nodes, but when you edit, it's not retrieving/update the right language node. Instead, it keeps on updating the source language node.

For some particular reason, when you create new IEF node and Save, and click on edit, the the loading seems to be 'stucked'. It happens on certain IEF fields only.

villette’s picture

I had the same problem with the parent of my node being a field_collection_item, so it was not translatable. I did this path in a hurry to meet my needs and it's far from complete, but maybe with a little more work it would be more adapted to anyone.

paravibe’s picture

122.21 KB
117.74 KB

Found a new problem. With title module enabled I am trying to save node and first time always get error that 'Title field is required'.
After entering title again and pushing save second time node saves properly.
I discovered that first time when node is building language for title field == 'und'. Second time it's build with proper language.
Will debug and try to solve.

damiankloip’s picture

The patch in #6 solved my issue, but we use value elements for languages on entity forms, using Entity Translation. So this needs to account for value elements too.

Cedric @Actualys’s picture

Here is my patch which solves issue on new node with translatable fields and after adding new language for an existing node.
This patch integrates the #14 and goes over.

Cedric @Actualys’s picture

The previous file includes a wrong filepath

agoradesign’s picture

Hi Cedric,
could you please provide an Interdiff? (https://www.drupal.org/documentation/git/interdiff)

Would be very helpful for all of us!

Sebastien @Actualys’s picture

2.89 KB

Follow the interdiff from Cedric patch.
It has been done between #14 and #16 patches.

damiankloip’s picture

I have not looked into why yet, but that latest patch throws some errors for me, and makes the IEF widget disappear in some cases. I will look into. In theory, that patch looks like it is making some nice changes though.

Cedric @Actualys’s picture

Resolved PHP notice about non existant array key when trying to get the current language of an inline entity form embedded in an inline entity form.

devad’s picture

Status: Needs review » Reviewed & tested by the community

patch #16 together with Cedric's #20 one line addition works for me.

Proper language is assigned to new enities both when new parent entity is created and existing one edited.

MXT’s picture

Status: Reviewed & tested by the community » Needs work


  1. patch #16 +
  2. patch #20 +
  3. patch in #1545896: Add Entity Translation integration

I receive the following notices:

    Notice: Undefined index: items_count in field_multiple_value_form() (line 188 of /var/www/my-site/modules/field/field.form.inc).
    Notice: Undefined index: instance in field_widget_instance() (line 603 of /var/www/my-site/modules/field/field.form.inc).
    Notice: Undefined index: field in field_widget_field() (line 578 of /var/www/my-site/modules/field/field.form.inc).
    Notice: Undefined index: instance in field_widget_instance() (line 603 of /var/www/my-site/modules/field/field.form.inc).
    Notice: Undefined index: field in field_widget_field() (line 578 of /var/www/my-site/modules/field/field.form.inc).
    Notice: Undefined index: instance in field_widget_instance() (line 603 of /var/www/my-site/modules/field/field.form.inc).

And the following anomalies:

  • After the above notices, the parent node can not be saved because its title is stripped out (you have to rewrite it to save)
  • (this is ok) After saving the referenced sub nodes are saved with the correct language (as the parent one)
  • Adding a translation of the parent node (with entity_translation), all existing referenced nodes are missing on save.
a.milkovsky’s picture

Status: Needs work » Needs review
3.37 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

Patches #16 + #20 work.
Merged them, fixed typos. Also updated with the latest dev.

I receive the following notices:

the parent node can not be saved

Please do not apply patches from https://www.drupal.org/node/1545896. It is a separate issue.

a.milkovsky’s picture

2.18 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
+++ b/inline_entity_form.module
@@ -1508,7 +1521,19 @@ function inline_entity_form_field_attach_submit($parent_entity_type, $parent_ent
-      $langcode = $form[$field_name]['#language'];
+      // Check inline entity translation fallback parent.
+      if (!empty($form_state['entity_translation']['is_translation']) && $form_state['entity_translation']['is_translation'] == TRUE) {
+        $langcode = $form_state['entity_translation']['form_langcode'];
+      }
+      else {
+        $field = field_info_field($field_name);
+        $langcode = ($field['translatable'] ? $parent_entity->language : $form[$field_name]['#language']);
+      }
+      if (!isset($form[$field_name][$langcode]['#ief_id']) && isset($form[$field_name][LANGUAGE_NONE]['#ief_id'])) {
+        $form[$field_name][$langcode]['#ief_id'] = $form[$field_name][LANGUAGE_NONE]['#ief_id'];
+        unset($form[$field_name][LANGUAGE_NONE]);
+      }

I don't understand why do we need this. Entity reference fields usually are not marked as translatable.
Also this code introduces an issue. Entity reference field value is removed on save.
I just removed this change.

devad’s picture

@a.milkovsky #24

Entity reference fields usually are not marked as translatable.

From my point of view, translatable entityreference fields are not rare in multilingual projects.

I use translatable entityreference fields in multilingual projects regularly (referencing all kinds of bundles: nodes, terms, products...).

a.milkovsky’s picture

Agree, that's required if you use "content translation".
I should have added that I wrote in context of "entity translation". With Entity Translation you dont need to create another entity for translation, but only translate fields.
See a nice presentation from Schnitzel: Get ready for full translated sites with Entity Translation

agoradesign’s picture

It's true, that you don't need to, but you may want to. And there are several circumstances, where you/your customer may want or even need this.

For example, imagine you use Entity Reference with IEF heavily to build a flexible layout (use entities for creating page sections/widgets). If you were forced to have the ER field language neutral, you lose the flexiblility to have a slightly different content for any of your other languages. You'd have to translate every existing entity, no possibility to remove one in german and add an additional section in french, etc

a.milkovsky’s picture

Status: Needs review » Needs work

@agoradesign, interesting thoughts. Actually I do use "Entity Reference with IEF heavily to build a flexible layout", but the content is the same for each language. Let's set the issue to needs work for such use cases.

If you don't need to have different content per language - use #24.

Else next thing needs to be fixed in #23
"Entity reference field values are removed on save."

devad’s picture

If you don't need to have different content per language - use #24.

I have such usecase and #24 works for me. Thanx a.milkovsky.

I have Administration Language module enabled and I have tested #24 patch with various admin languages selected. And #24 patch works properly for me regardless of selected admin language.

maxplus’s picture


just a note:

when using patch #24 everything works perfect except in one situation:

=> when I disable the option "Allow users to add existing products" in the IEF-settings of my product reference field

I think the reason could be the fact that the IEF in that situation is already expanded in the node edit form on creation of a new node.
When the setting "Allow users to add existing products" is enabled, you first have to click the button "add new product" and maybe only then the language is captured from its surrounding display node...

douggreen’s picture

Rerolled patch for 7.x-1.6, it didn't apply cleanly anymore.

brahimmouhamou’s picture

I'm using Bean blocks in combination with IEF v1.6.

When I try to translate a node with entity references I get the following error:
Notice: Undefined index: form_langcode in inline_entity_form_field_widget_form() (line 413 of drupal-root/sites/all/modules/contrib/inline_entity_form/inline_entity_form.module).

vasike’s picture

It seems the patches here won't help to add new translations with latest IEF version.

There is a new issue with patch that helps to create new translation : #2475829: Entity Translation broken: Call to a member function entityFormValidate() .
Maybe it could help here too.

Musa.thomas’s picture

Here a new patch wich work with 7.x-1.8 and entity translation

zarexogre’s picture

I can confirm the 1.8 is good, but you need to upgrade entity translation module to 7.x-1.0-beta5.

mayap’s picture

Hello Zarrex,

As you've confirmed that the inline entity form translation works for you, I just wanted to ask you, have you applied any patches to the module in order to get it working. I am still trying but when I try to translate the entity, it gets saved and updates all other available languages.

zarexogre’s picture

I have dev version of IEF and patches 2028711, 2475829. I also have entity translation 1.0-beta3 with no patches, all seems to be working fine. Hope this helps.

zarexogre’s picture

Sorry to say my experience with IEF and entity translations has not resulted in a working situation. I thought it was working but after through testing noticed there were problems. I have IEF 1.8 with this patch and the patch from here https://www.drupal.org/node/1545896 and I have latest entity translations beta5. I have tried many different setups but I have 2 setups which seem most promising:

1: I have field translations on, on the parent content type but off on the child. I have applied both patches. Translations work but the override parent issue remains.

2: I have translations off on the parent and field translations on, on the child. The override parent bug is gone but the translations do not work.

I have been trying for a long time to get entity translations working and I have noticed allot of issues in the queue for translations. Could someone who has entity translations and IEF working give some advice on their setup i.e. what translations settings you have and what versions/patches you are running.

At the moment I feel like IEF doesn't support entity translations but would love for someone to prove me wrong, thanks for any advice.

danabel’s picture

I have a working solution although my setup isn't quite the same as the OP.

I have IEF 7.x-1.x-dev with this patch: https://www.drupal.org/files/issues/add_entity_translation-1545896-152.p... (Issue: https://www.drupal.org/node/1545896) to add entity translation support.

I think it comes down to the incompatibility between Entity Translation and Multilingual Content as discussed here: https://www.drupal.org/node/1852102. With Multilingual Content (i18n_node) disabled it works as expected for me.

I have field translation turned on in both node types but the Entity Ref field itself is not translatable as I want all languages to reference the same child node. Now when I create a new node in a specified language a child node is also created in the same language. And I'm happy!

SocialNicheGuru’s picture

The patch in #34 introduces an error:

Notice: Undefined index: #default_value in inline_entity_form_field_widget_form() (line 505 of modules/all/inline_entity_form/inline_entity_form.module).

I only had $form['language']['#value'] not '#default_value