When you're inline editing entities, the language of the parent entity is to be respected.
So:
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).

Comments

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

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?

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

Just checking if there is any progress in making this work properly for multilingual sites...

Assigned:Unassigned» Amitaibu

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.

Next is to make sure language is handled correctly when entity still doesn't exists (e.g. node/add/parent-entity)

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

Status:Needs work» Needs review
StatusFileSize
new7.09 KB

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

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

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.

Status:Needs work» Needs review
StatusFileSize
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.

@bojanz,
Can you "Enable automated testing"?

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

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?

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.

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?

Title:Make IEF language awareAdd Entity Translation integration
Assigned:Amitaibu» Unassigned
Category:task» feature
Status:Needs review» Active

@idflood
Yes, that's right.
When you're inline editing entities, the language of the parent entity is to be respected.
So:
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.

Issue summary:View changes

Updated summary.

Status:Active» Needs review
StatusFileSize
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.

I am devoting my day tomorrow to testing and completing this.

@Everyone
Please buy plach a beer when you see him. He certainly deserves a case or two :)

:)

@@ -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?

The patch supports only the single-entity widget, @bojanz may be working on improving it.

@bojanz:

Any news?

any news?

Do you tink that this post can be related to this issue?

http://drupal.org/node/1982670

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

Yep, the patch currently provides ET integration only for single-entity widgets.

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.

Priority:Normal» Major

in #21 Bojanz wrote:

I am devoting my day tomorrow to testing and completing this.

@Everyone
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

StatusFileSize
new14.3 KB

Rerolled aginst the latest dev, it would be good to have some feedback sooner or later :)

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.

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

@plach
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)

Status:Needs review» Needs work
StatusFileSize
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

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

Issue summary:View changes

And again.

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.

Issue summary:View changes
StatusFileSize
new17.73 KB

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

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

Status:Needs work» Needs review

For #41

StatusFileSize
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

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
ResponseText:

Re-rolled patch against latest dev release.

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.

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

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.

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.

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