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

#144 inline_entity_form-add_entity_translation-1545896-144.patch29.83 KBadinac
#108 inline_entity_form-entity_translation-1545896-110.patch29.79 KBjclander
#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
#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 entity-translations-1545896-48.patch17.24 KBgarphy
#7 Selection_081.png50.24 KBitamar
#7 Selection_082.png27.36 KBitamar
#7 Selection_083.png28.85 KBitamar


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' => '
', '#markup' => t('You need to save this page first in order to add entities.'), '#suffix' => '
', ); } } }

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?


jclander’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 :)

Emerya.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) {
Emerya.thomas’s picture

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

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

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