Closed (fixed)
Project:
Entity Translation
Version:
7.x-1.x-dev
Component:
Base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
25 Feb 2015 at 22:17 UTC
Updated:
15 Apr 2017 at 14:20 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
David_Rothstein commentedHere's a patch that solves the issue for me.
It might not be fully working correctly in the case where the language selector is exposed on the node form and someone changes it from the default while creating the node. In that case, if you change the dropdown from English to French while creating, then during the validation phase the field values are in $node->{$field_name}['en'] still, rather than $node->{$field_name}['fr'], whereas for taxonomy terms they are correctly in 'fr'. The discrepancy is because EntityTranslationNodeHandler::entityFormLanguageWidgetSubmit() doesn't do all the same things its parent function does. If I remove that override and let the parent run, the whole thing breaks... so whatever the solution to that is, it's more complicated.
But this patch makes things work fine in the case where the language selector is not exposed on the node form.
Comment #2
David_Rothstein commentedReroll fixing a code comment typo.
Comment #5
David_Rothstein commentedI am seeing all sorts of test failures locally even without this patch applied, so I don't think the failures are related.
Comment #8
David_Rothstein commentedWell, I'm not sure what this means actually. Those tests are also failing for me locally without the patch. But another patch I just posted (#2442287: Provide an API function to return all languages that have a translation for the given entity and field) passes the testbot just fine.
Comment #9
David_Rothstein commentedOK, I actually can reproduce test failures locally specifically caused by this patch. Not sure what I was seeing the other day.
This looks like it's just because the tests were assuming the buggy behavior (that translatable fields would be entered via LANGUAGE_NONE when creating a new node) that this patch fixes.
Addressed in the attached.
Comment #10
jorditr commentedI have the same problem and your code, which looks very logical, it's not working for me at all.
Comment #12
matthiasm11 commentedPatch #9 worked for me. Code is very logical.
My setup: a commerce product with inline entity form inside a new node product display, both with entity translation enabled and a default language different from language_none (dutch in my case, configurated at admin/config/regional/entity_translation) The parent node product display did not have a language yet when on the creation form. Therefore, the child commerce product did not have a language from the #parent_language. Because of that, commerce product validation failed on some fields, making the fields (like commerce product title from the title module or adding images through the media module) became empty.
Cross referencing a related issue, going to use this approach because this solution is more general.
Comment #13
stefanos.petrakisThank you very much for the code contribution (with the test mods) as well as the review.
The code is very logical, I did think of restructuring it some, since this seems to be node-specific (and therefore would have a natural place inside the
EntityTranslationNodeHandler's owngetFormLanguage()implementation). However, after checking I found that:This patch will effectively solve the same issue for comments as well.
So, accepted and thanks again!
Comment #14
stefanos.petrakisComment #15
stefanos.petrakisComment #17
matthiasm11 commentedThanks for the quick follow up, Stefanos!
Comment #19
czigor commentedCreated #2856927: getActiveLanguage() should delegate its logic elsewhere. that proposes a different approach after #2849464: Add an API to set active language has been fixed.
Comment #20
joseph.olstadFollowup issue for regression #2863794: Translated content is lost when cloning