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

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

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

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

Comments

ordermind’s picture

Priority:Major» Normal

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

ordermind’s picture

Priority:Normal» Major
vmichnowicz’s picture

Priority:Normal» Major

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

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

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

I can confirm this problem.

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

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

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

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

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

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

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

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

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

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

ayalas’s picture

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

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

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

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

marcusx’s picture

StatusFileSize
new1.66 KB

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

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

maxplus’s picture

Hi,

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

Thanks already for the effort!

marcusx’s picture

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

olofjohansson’s picture

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

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

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

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

AdamGerthel’s picture

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

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

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

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

jonloh’s picture

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

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

villette’s picture

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

paravibe’s picture

StatusFileSize
new122.21 KB
new117.74 KB

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

damiankloip’s picture

StatusFileSize
new1.78 KB
new1.05 KB

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

Cedric @Actualys’s picture

StatusFileSize
new3.82 KB

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

Cedric @Actualys’s picture

StatusFileSize
new3.68 KB

The previous file includes a wrong filepath

agoradesign’s picture

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

Would be very helpful for all of us!

Sebastien @Actualys’s picture

StatusFileSize
new2.89 KB

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

damiankloip’s picture

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

Cedric @Actualys’s picture

StatusFileSize
new628 bytes

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

devad’s picture

Status:Needs review» Reviewed & tested by the community

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

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

MXT’s picture

Status:Reviewed & tested by the community» Needs work

Using:

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

I receive the following notices:

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

And the following anomalies:

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

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

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

I receive the following notices:

the parent node can not be saved

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

a.milkovsky’s picture

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

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

devad’s picture

@a.milkovsky #24

Entity reference fields usually are not marked as translatable.

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

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

a.milkovsky’s picture

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

agoradesign’s picture

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

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

a.milkovsky’s picture

Status:Needs review» Needs work

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

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

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

devad’s picture

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

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

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