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
Comment #1
ordermind CreditAttribution: ordermind commentedI'm also experiencing this problem, and it makes translating product titles in Drupal Commerce a real hassle.
Comment #2
ordermind CreditAttribution: ordermind commentedComment #3
vmichnowicz CreditAttribution: vmichnowicz commentedI 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.
Comment #4
marcusx CreditAttribution: marcusx commentedI 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)
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 inlocale_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.Maybe someone knows a better solution. But so far I don't get any side effects. Please review.
Comment #5
ayalas CreditAttribution: ayalas commentedAfter applying this patch, when I enter the "Add product" page for the "Product Display" entity I get this error:
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'];
Comment #6
marcusx CreditAttribution: marcusx commentedAdding 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.Comment #7
maxplus CreditAttribution: maxplus commentedHi,
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!
Comment #8
marcusx CreditAttribution: marcusx commentedI 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.
Comment #9
olofbokedal CreditAttribution: olofbokedal commentedI 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.
Comment #10
AdamGerthel CreditAttribution: AdamGerthel commentedI 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?
Comment #11
jonloh CreditAttribution: jonloh commentedPatched 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.
Comment #12
villette CreditAttribution: villette commentedI 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.
Comment #13
paravibe CreditAttribution: paravibe commentedFound 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.
Comment #14
damiankloip CreditAttribution: damiankloip commentedThe 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.
Comment #15
Cedric @Actualys CreditAttribution: Cedric @Actualys at Actualys commentedHere 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.
Comment #16
Cedric @Actualys CreditAttribution: Cedric @Actualys at Actualys commentedThe previous file includes a wrong filepath
Comment #17
agoradesign CreditAttribution: agoradesign commentedHi Cedric,
could you please provide an Interdiff? (https://www.drupal.org/documentation/git/interdiff)
Would be very helpful for all of us!
Comment #18
Sebastien M. CreditAttribution: Sebastien M. commentedFollow the interdiff from Cedric patch.
It has been done between #14 and #16 patches.
Comment #19
damiankloip CreditAttribution: damiankloip commentedI 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.
Comment #20
Cedric @Actualys CreditAttribution: Cedric @Actualys at Actualys commentedResolved 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.
Comment #21
devad CreditAttribution: devad commentedpatch #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.
Comment #22
MXTUsing:
I receive the following notices:
And the following anomalies:
Comment #23
a.milkovskyPatches #16 + #20 work.
Merged them, fixed typos. Also updated with the latest dev.
Please do not apply patches from https://www.drupal.org/node/1545896. It is a separate issue.
Comment #24
a.milkovskyI 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.
Comment #25
devad CreditAttribution: devad commented@a.milkovsky #24
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...).
Comment #26
a.milkovskyAgree, 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
Comment #27
agoradesign CreditAttribution: agoradesign commentedIt'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
Comment #28
a.milkovsky@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."
Comment #29
devad CreditAttribution: devad commentedI 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.
Comment #30
maxplus CreditAttribution: maxplus commentedHi,
just a note:
when using patch #24 everything works perfect except in one situation:
=> when I disable the option "Allow users to add existing products" in the IEF-settings of my product reference field
I think the reason could be the fact that the IEF in that situation is already expanded in the node edit form on creation of a new node.
When the setting "Allow users to add existing products" is enabled, you first have to click the button "add new product" and maybe only then the language is captured from its surrounding display node...
Comment #31
douggreen CreditAttribution: douggreen commentedRerolled patch for 7.x-1.6, it didn't apply cleanly anymore.
Comment #32
brahimmouhamou CreditAttribution: brahimmouhamou commentedI'm using Bean blocks in combination with IEF v1.6.
When I try to translate a node with entity references I get the following error:
Notice: Undefined index: form_langcode in inline_entity_form_field_widget_form() (line 413 of drupal-root/sites/all/modules/contrib/inline_entity_form/inline_entity_form.module).
Comment #33
vasikeIt seems the patches here won't help to add new translations with latest IEF version.
There is a new issue with patch that helps to create new translation : #2475829: Entity Translation broken: Call to a member function entityFormValidate() .
Maybe it could help here too.
Comment #34
Musa.thomasHere a new patch wich work with 7.x-1.8 and entity translation
Comment #35
zarexogre CreditAttribution: zarexogre as a volunteer commentedI can confirm the 1.8 is good, but you need to upgrade entity translation module to 7.x-1.0-beta5.
Comment #36
mayap CreditAttribution: mayap commentedHello Zarrex,
As you've confirmed that the inline entity form translation works for you, I just wanted to ask you, have you applied any patches to the module in order to get it working. I am still trying but when I try to translate the entity, it gets saved and updates all other available languages.
Comment #37
zarexogre CreditAttribution: zarexogre as a volunteer commentedI have dev version of IEF and patches 2028711, 2475829. I also have entity translation 1.0-beta3 with no patches, all seems to be working fine. Hope this helps.
Comment #38
zarexogre CreditAttribution: zarexogre as a volunteer commentedSorry to say my experience with IEF and entity translations has not resulted in a working situation. I thought it was working but after through testing noticed there were problems. I have IEF 1.8 with this patch and the patch from here https://www.drupal.org/node/1545896 and I have latest entity translations beta5. I have tried many different setups but I have 2 setups which seem most promising:
1: I have field translations on, on the parent content type but off on the child. I have applied both patches. Translations work but the override parent issue remains.
2: I have translations off on the parent and field translations on, on the child. The override parent bug is gone but the translations do not work.
I have been trying for a long time to get entity translations working and I have noticed allot of issues in the queue for translations. Could someone who has entity translations and IEF working give some advice on their setup i.e. what translations settings you have and what versions/patches you are running.
At the moment I feel like IEF doesn't support entity translations but would love for someone to prove me wrong, thanks for any advice.
Comment #39
danabel CreditAttribution: danabel commentedI have a working solution although my setup isn't quite the same as the OP.
I have IEF 7.x-1.x-dev with this patch: https://www.drupal.org/files/issues/add_entity_translation-1545896-152.p... (Issue: https://www.drupal.org/node/1545896) to add entity translation support.
I think it comes down to the incompatibility between Entity Translation and Multilingual Content as discussed here: https://www.drupal.org/node/1852102. With Multilingual Content (i18n_node) disabled it works as expected for me.
I have field translation turned on in both node types but the Entity Ref field itself is not translatable as I want all languages to reference the same child node. Now when I create a new node in a specified language a child node is also created in the same language. And I'm happy!
Comment #40
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedThe patch in #34 introduces an error:
Notice: Undefined index: #default_value in inline_entity_form_field_widget_form() (line 505 of modules/all/inline_entity_form/inline_entity_form.module).
I only had $form['language']['#value'] not '#default_value
Comment #41
papegaill CreditAttribution: papegaill commentedPatch #31 worked for me, but I can't apply for 1.8 module version.
Here is the correct patch file for that version:
Comment #42
papegaill CreditAttribution: papegaill commentedComment #43
devad CreditAttribution: devad commentedHi
ief-fix_new_translation_1.8.patch does not apply cleanly to v1.9.
Needs reroll.
Comment #44
devad CreditAttribution: devad commentedReroll against latest .dev
Update. Hm... it seems that something is wrong. Hiding the file.
Comment #45
devad CreditAttribution: devad commentedComment #46
devad CreditAttribution: devad commentedReroll against v1.9
Comment #47
devad CreditAttribution: devad commentedAdding a pair of curly brackets around
$parent_entity_info['entity keys']['id']
to avoid PHP notice:$element['#entity']->{$parent_entity_info['entity keys']['id']}
That's one error less, but tests are failing still... it's outside of my skill to repair further.