If you configure entity translation for nodes and taxonomy terms, and set up both to use English as the default language, you'll see the following discrepancies:

  1. For taxonomy terms, the entity form is correctly built using English. Translatable field use an 'en' key in the form structure, and after form submission (during the validation step, e.g. field_attach_validate()) the entity correctly has those fields stored in $taxonomy_term->{$field_name}['en'] throughout.
  2. For nodes, this does not happen. The form is built using LANGUAGE NONE and remains that way throughout the form validation process (translatable fields use an 'und' key in the form structure, and during field_attach_validate() the submitted values are in $node->{$field_name}['und'] even though $node->language is 'en'. It doesn't straighten itself out until form submit handlers are run.

This can cause issues with any code running during form validation which is trying to examine the node and see the submitted values. Functions like the Entity module's ->value() method will not return the submitted value because the languages don't match up.

Comments

David_Rothstein’s picture

Status: Active » Needs review
StatusFileSize
new1.09 KB

Here'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.

David_Rothstein’s picture

Reroll fixing a code comment typo.

The last submitted patch, 1: entity-translation-form-language-2438615-1.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 2: entity-translation-form-language-2438615-2.patch, failed testing.

David_Rothstein’s picture

Status: Needs work » Needs review

I am seeing all sorts of test failures locally even without this patch applied, so I don't think the failures are related.

Status: Needs review » Needs work

The last submitted patch, 2: entity-translation-form-language-2438615-2.patch, failed testing.

David_Rothstein’s picture

Status: Needs work » Needs review

Well, 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.

David_Rothstein’s picture

OK, 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.

jorditr’s picture

I have the same problem and your code, which looks very logical, it's not working for me at all.

matthiasm11’s picture

Status: Needs review » Reviewed & tested by the community
Related issues: +#2224915: Images empty when editing products using inline entity form

Patch #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.

stefanos.petrakis’s picture

Status: Reviewed & tested by the community » Fixed
StatusFileSize
new2.25 KB

Thank 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 own getFormLanguage() implementation). However, after checking I found that:

  • New Taxonomy terms and Users object stubs come without a language set from their respective form builders; entity translation can correctly switch to their default language
  • New Nodes and Comments object stubs come with 'und' set from their respective form builders; entity translation cannot correctly switch to their default language, as identified by this issue

This patch will effectively solve the same issue for comments as well.
So, accepted and thanks again!

stefanos.petrakis’s picture

stefanos.petrakis’s picture

  • stefanos.petrakis committed 1d54935 on 7.x-1.x
    Issue #2438615 by David_Rothstein, matthiasm11: New nodes are always...
matthiasm11’s picture

Thanks for the quick follow up, Stefanos!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

czigor’s picture

joseph.olstad’s picture