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.