Content can not be created in another language as the one chosen by configuration

Hi Simon,
I think you're facing the same issue as I was facing couple days ago. I've tried to analyze the reason of why it is happening in this thread https://www.drupal.org/node/2870524#comment-12077074
Can you try proposed patch and check if it resolves your issue? Apparently there was some reason for changing the logic of getFormLanguage() method in beta6/dev version of module.

The patch available at #2877074-3: Refactor the entity_translation_language() callback to make it bundle-specific should solve this issue as well, following a different approach.

Hello @Simon,

I am trying to reproduce your issue, to be sure we are not missing sth important.
I cannot reproduce it though on the latest 7.x-1.x-dev, without any patches applied.
Which is the exact tag/version that caused the problem?

Hello @Simon,

I tried wtih ET-B6 and I still cannot reproduce it, just tried it on simplytest me:

7.54 + ET-B6; en + fr as languages, en is default; Article has Field Translation enabled, Article->Body is multilingual, Article->DefaultETLanguage is current language.

On creating a new node, I switch the language selector to fr, add some content to body and save.
The newly created node is in fr, the content in fr and editing seems to work as expected.

Any other clues about your set up?

Hey @Simon, thanks for the patience. I am using the default empty prefix for english, with both Interface and Content detection set to URL.
My "Add article" URL looks like this then:

http://localhost/node/add/article

I also tried replacing the empty prefix with the 'en' prefix and got such a URL:

http://localhost/en/node/add/article

But, I still managed to create the content in the language I selected in the "Language" dropdown, the current language was not enforced.

You can check the setup I used here => https://rcneb.ply.st/ (admin:admin)
A sample article, created with the current language being 'en' and setting the form's language to 'fr' is here => https://rcneb.ply.st/fr/node/1/devel, and it seems to be created as expected.

I am experiencing this issue with 7.x-1.0

My content type is configured as per the attached screenshot.

If I goto /fr/node/add/document and then select English from the language field, the fields get saved with the language of fr.

Debugging from a hook_node_validate I can see that the field values already have the wrong language at this point.

If I change the configuration so that the default language is 'Language neutral', then the problem does not occur, but the language value in the form is not pre-populated with the user's language, which isn't ideal.

Applying the change in #2 appears to fix the issue.

Hi @drasgardian, will set this back to "active" and try to have a look soon following your set-up. Thanks for the update

Hello @drasgardian:

I managed to reproduce the error you described.

Here is a first try at fixing this. Using the patch from #2 is not advised as it essentially rolls back meaningful and intended changes (see #2438615: New nodes are always created using LANGUAGE_NONE (only changed to the correct language during form submission)).

Please have a try a let me know if that solves your issue.

I finally managed to write some tests that can successfully capture the problem described in #14.
There seems to be some interplay of the Locale's module locale_field_entity_form_submit() that calls entity_language() passing it an instantiated entity object that is lacking the translation handler id (see that function's code for more info).

So, first off: The test I wrote (entity_translation-content_not_in_current_language-2877103-17_tests.patch) can capture the problem that @drasgardian reported in #14 and should fail when run alone.

Secondly, the patch I provided in #16 should take care of solving the issue and is very similar to the patch provided in comment #34 here (I will give credit accordingly).
The updated patch (entity_translation-content_not_in_current_language-2877103-17.patch) contains the new test - which should now pass - as well as small changes of the patch from #16.

Finally, a note for the E.T. code enthusiasts: I had to modify the EntityTranslationFactory::getHandlerId() code slightly to make sure that no "translation handler hi-jacking" takes place, i.e. new entities with no translation handlers assigned to them getting linked to existing handlers. This was particularly painful while writing the test case for #14, since I couldn't reproduce the problem inside Simpletest, even though I could easily reproduce it on the browser. After log debugging I came to the conclusion that inside Simpletest, somehow the issue with Locale does not manifest itself due to "translation handler hi-jacking".

@drasgardian: Much appreciated if you can give some feedback regarding this, specifically after applying entity_translation-content_not_in_current_language-2877103-17.patch

I would like to see this committed soon since the proposed changes take care of the Locale module's problematic logic (instantiating the current entity using a object derived from the $form_state['values'] array) which is causing trouble to Entity Translation's language detection/definition logic.

I would really appreciate @drasgardian's feedback since he guided me to reproducing the error in #14; the latest patch should allow the error to be resolved, can you confirm this @drasgardian?

I will otherwise review the patch on my own and try to push this into dev in the following days.

P.S.: Raising this to Major to get some attention

#17 worked for me

The way I tested was to:

• install latest drupal 7 and entity_translation
• add a new language
• create a new content type with "Enabled, with field translation"
• add node with new language as base

Result: in view content shows, in edit content shows, all good

without the patch its not the case.

I've tested also different values in admin/config/regional/entity_translation and also with workbench_moderation, all good.

Hi Andras,

Very happy you could test this.
I tried to do this manually again, just to be sure.
But, I cannot reproduce the problem any more:

1. On a fresh D7.67 install, with ET 7.x-1.0
2. Two languages, English default (without URL prefix) and German with 'de' as URL prefix
3. Enabled ET for the Article content type, with default language set to "current language" and language locking enabled
4. Enabled field translation for the body field ofthe Article content type
5. Visited the /de/node/add/article URL, switched the language selector to "English", added some text to the body field and saved

Contrary to what I expected, the new node had correctly saved the value into the correct field's language sub-array (body[en]).

Can you check my steps and let me know if I missed sth? Or, otherwise, give me some more details of how to reproduce the breakage?

Thanks again!

Hi Stefanos,

the trick is to create the page from /en/node/add/article and select German from the dropdown.

In our use case we have sites in many languages, the content creators would browse in english and create content for the language needed.

Let me know if this makes sense for you.

Thanks Andras,

Will have another try and set it back to RTBC accordingly!

Hi Andreas, Still cannot reproduce it, hear are the steps:

1. On a fresh D7.67 install, with ET 7.x-1.0
2. Two languages, English default (with 'en' as the URL prefix) and German with 'de' as URL prefix
3. Enabled ET for the Article content type, with default language set to "current language" and language locking enabled
4. Enabled field translation for the body field ofthe Article content type
5. Visited the /en/node/add/article URL, switched the language selector to "German", added some text to the body field and saved

The new node had correctly saved the value into the correct field's language sub-array (body[de]).

Please check the steps I describe here to help me reproduce the error.

Hi Styefanos,

with the config u mention, create the page from /en/node/add/article and select German from the dropdown.

after go back to edit, you will see body content missing.

Hi Andras, thanks for the update, still no luck, on this instance https://stm5dcd1c1acfa3d-o0818l03j9gprixwqmtfzyapdfiottad.tugboat.qa/en/... (simplytestme)

Here are the visuals, problem still not reproducible:

@stefanos & @andras I think i "resolved" this mistery :)

When i apply @stefanos' steps i can indeed not reproduce the issue.
However, I can reproduce it if i create a new content type.

STEPS [same as yours]
On a fresh D7.67 install, with ET 7.x-1.0
Two languages, English default (with 'en' as the URL prefix) and German with 'de' as URL prefix
Enabled ET for the Article content type, with default language set to "current language" and language locking enabled
Enabled field translation for the body field ofthe Article content type
Visited the /en/node/add/article URL, switched the language selector to "German", added some text to the body field and saved

The new node had correctly saved the value into the correct field's language sub-array (body[de]).

Then, i create a Forum content type, using ET with default language set to "current language" and language locking enabled, body field is enough.
Visited the /en/node/add/forum URL, switched the language selector to "German", added some text to the body field and saved
The new forum node has an empty body in edit mode...

This makes sense when you look at the patch comments :/

Here are some screenshots

I've made a screencast

Hmm I have found even easier repro steps !

STEPS
On a fresh D7.67 install, with ET 7.x-1.0
Two languages, English default (with 'en' as the URL prefix) and German with 'de' as URL prefix
Enabled ET for the Article content type, with default language set to "current language" and language locking enabled
Enabled field translation for the body field of the Article content type *and delete tags and image fields*
Visited the /en/node/add/article URL, switched the language selector to "German", added some text to the body field and saved

body is empty on edit mode !

Thank you both for the fantastic help, very, very much appreciated.

I found the reason for not being able to reproduce the problem.
Delphine Lepers had found that too in her last comment; there is a case of form caching that causes the error not to manifest itself on forms where there are ajax-enabled elements.
This is the code responsible for caching (from includes/ajax.inc).

function ajax_process_form($element, &$form_state) {
  $element = ajax_pre_render_element($element);
  if (!empty($element['#ajax_processed'])) {
    $form_state['cache'] = TRUE;
  }
  return $element;
}

Which means that node types with no ajax-enabled fields will exhibit the erroneous behaviour and others, like I encountered in my test, e.g. the Article node type, with its ajax-enabled image field will not demonstrate the problem.
I updated the tests and I actually managed to capture the error by activating the caching on the node add form.

Re-rolling the tests and patch, we are very close to an end here and this will definitely trigger a new release as it is quite a significant fix.

Great, bot said we are ok, I just committed this and assigned credits accordingly, including people that participated in the related issue #2870524: Field copy fails with content translation for fields with entity translation enabled.

Thanks again to Delphine Lepers and Andras_Szilagyi: Your help was really invaluable!