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


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

new1.81 KB

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
new7.09 KB

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

itamar’s picture

new6.87 KB

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

new7.04 KB
new7.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
new14.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

new14.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
new3.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

netdream’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

netdream’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
new17.73 KB
rsmylski’s picture

new18.31 KB

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

...good practice to hide old patches when uploading new ones ;)

MXT’s picture

Status:Needs work» Needs review

For #41

JeroenT’s picture

new46.82 KB

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

new18.27 KB

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

new17.24 KB
new1.39 KB
-    $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

new17.25 KB
new841 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? :)

seb_tsolutions’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

new101.3 KB

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

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

just the #64 working with 1.x-dev

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.