Field copy fails with content translation for fields with entity translation enabled

I updated the issue adding the steps to reproduce the problem. Edit at will if you notice sth odd.
And here is a patch for you to have a go at.

Most importantly, this code can adjust the entity being prepared for translation (using content translation), and call setActiveLanguage() on its EntityTranslationHandler to set the correct active language.

Ref: field_attach_prepare_translation

Excellent. For completeness I would like to have tests added for this case, I will set this to "Needs work" and will try to work and provide some testing code in the next days. Unless you are faster. ;)

Thanks for checking and happy it worked for you.

Here is a test which covers the case described in the issue's description, and the submitted code subsequently.

Thanks for the check Joseph, one minor last change, I will change the message of the last assertion, from:

"Original body value correctly populated."

to

"Body field correctly instantiated with the value of the source language".

Will update that on commit.

Yep, quite some noise here :-)
Good that this PEBKAC happened while I was AFK.
And in any case, happy this was a false alarm.
Cheers

Trapped with the issue mentioned in #13 after update of entity translation from beta5 to beta6 and applying #9 patch.

System configuration:
- English language is default;
- German enabled as second language;
- Content type with "Multilingual support" set into "Enabled, with translation".
- Part of the fields are translatable as per "Field translation" option on field edit page.

When issue occurs:
- Original node is being created in default language (EN).
- Translation form gets original values for multilingual fields thanks to the patch #9.
- After node is being saved - everything looks fine, but when translated node is being edited - multilingual fields are empty.

What seems to be happen in the backend:
- As a final step - node has multilingual fields saved with the wrong keys (eg $node->field['en'][0]['value'] instead of desirable $node->field['de'][0]['value']).
- After form is being submitted and when form submit handlers are not yet executed (includes/form.inc:1520 form_execute_handlers()) - $form_state['values'] array contains submitted data with the proper language keys. When it comes to locale_field_node_form_submit() and tries to get current entity language (modules/locale/locale.module:432 locale_field_entity_form_submit()) - it gets default language. It tries to load entity language with the updated getFormLanguage() method and always fall back to the default language because translated entity is new and no active language is set in the translation handler at this point. [This is the reason why field values are being visible on node edit form after second submit - getFormLanguage() gets active language properly in this case.]
- At the same time at locale_field_node_form_submit() $form_state['values'] array is being updated for the multilingual fields, basicaly input is being flipped - it removes all the values with proper language keys and sets all values as if they were set for default language.
- This mess-up field submit process (modules/field/field.attach.inc:890 field_attach_submit()) and incorrect values are beings saved inside of the node.

Update: problem occurs in "Locale" module because it takes $form_state['values'] array, converts it into the object and process field values basing on that information. Values array doesn't contain information about entity_translation_handler_id, which force EntityTranslationHandlerFactory to create new instance of translation handler (with no active language) when "Locale" tries to get current language of an entity. Proposed patch is in attachments.

Hi Joseph,
I've extended proposed patch with the new testcase which covers mentioned issue. Existing testcases were not covering this scenario.
Additionally checked that problem can be reproduced on clean drupal installation, so it's not something related to my environment.

Patch #30 can be applied on top of dev version of module.

Even without Content Translation enabled, this patch fixed the problem I mentioned in #2877103: Content can not be created in another language as the one chosen by configuration. Thanks!

Thanks for the patch! Visually the solution looks good to me, but I'll wait for Joseph to test it before committing it.

Meanwhile here a few minor remarks around coding standards and comments:

1. +++ b/includes/translation.handler.inc
   @@ -1533,8 +1533,9 @@ class EntityTranslationDefaultHandler implements EntityTranslationHandlerInterfa
   +   * @param $form_state
   

   Missing newline before @param and @param description.

2. +++ b/includes/translation.handler.inc
   @@ -1542,6 +1543,15 @@ class EntityTranslationDefaultHandler implements EntityTranslationHandlerInterfa
   +    // Pass entity_translation_handler_id into form_state if it's available
   

   Missing trailing dot, comma or colon :)

3. +++ b/includes/translation.handler.inc
   @@ -1542,6 +1543,15 @@ class EntityTranslationDefaultHandler implements EntityTranslationHandlerInterfa
   +    // "Locale" module uses $form_state['values'] as an entity object in it's
   

   its

4. +++ b/includes/translation.handler.inc
   @@ -1542,6 +1543,15 @@ class EntityTranslationDefaultHandler implements EntityTranslationHandlerInterfa
   +    // form state - entity language is not being determined correctly.
   

   Please replace the dash with a comma, to make the comment more readable.

5. +++ b/tests/entity_translation.test
   @@ -692,4 +723,20 @@ class EntityTranslationContentTranslationTestCase extends EntityTranslationTestC
   \ No newline at end of file
   

   This :)

Thanks for the remarks!
Here is the updated version of the patch with fixed coding standard issues which are mentioned above and which were listed here: https://www.drupal.org/pift-ci-job/668199 (only for the lines which were added).

Thank you all for the work so far. I will set this back to "Needs work", as I believe there is a less obscure alternative available over at #2877074: Refactor the entity_translation_language() callback to make it bundle-specific.

The patch from #2877074-3: Refactor the entity_translation_language() callback to make it bundle-specific (plus the one that solves the broken test #2877074-5: Refactor the entity_translation_language() callback to make it bundle-specific) makes writing the locale specific workaround (array2object property) unnecessary. Specifically, the call to entity_language() from locale_field_entity_form_submit() will now correctly get the node's set language, instead of being handled by an ET handler even though the node is not under ET's jurisdiction. In my view, that was the high-level problem, more than anything else.

And similar to the recent patches made available here (thank you @Alexander), that patch also solves the problem reported over at #2877103: Content can not be created in another language as the one chosen by configuration. Update: The problem in #2877103: Content can not be created in another language as the one chosen by configuration cannot be reproduced following the steps in the description and therefore patching it does not really provide any insights. I would ignore this for the time being, till we know how to reproduce that problem.

We could definitely keep the testFieldsSaveUsingContentTranslation tests provided here (I tested them separately together with the patches from #2877074: Refactor the entity_translation_language() callback to make it bundle-specific and they came out green).

One way or the other, we will get to the bottom of this pretty soon I believe.

Now that #2877074: Refactor the entity_translation_language() callback to make it bundle-specific has been commited (2100a4d) and as mentioned in #36, we don't need the code changes suggested.

I am rerolling the patch from #34 keeping the tests though, for the robot to test and to prove that the current dev now supports these cases.

So, the tests provided by @Alexander are passing as well as the rest of ET's tests.
It would be great if @Alexander could give some confirmation too, whether the problem is solved with the latest dev.
And then we can give this a push.

I am going to set this to RTBC as it's essentially extending the tests suite and will commit it soon-ish.

Regarding the tests: I had a better look at the tests provided in #34 and they don't provide any checks regarding Entity Translation, they are simple Content Translation tests.

I will not add the tests and close the issue as the OP has already been addressed.