Content moderation incorrectly always assumes a language is being added when the default language of an entity is being changed

It'd be awesome to get a test to confirm this, a kernel test should be fine.

It'll need fixing in 8.6.x before being backported to 8.5.x, it'll never be fixed in 8.4.x or 8.3.x.

I have the same error in 8.5 in a multilingual site + content moderation when I was trying to change an English node from French to English.

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">InvalidArgumentException</em>: Invalid translation language (und) specified. in <em class="placeholder">Drupal\Core\Entity\ContentEntityBase-&gt;getTranslation()</em> (line <em class="placeholder">866</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/ContentEntityBase.php</em>). <pre class="backtrace">Drupal\content_translation\Plugin\Validation\Constraint\ContentTranslationSynchronizedFieldsConstraintValidator-&gt;getOriginalTranslation(Object, Object) (Line: 111)
Drupal\content_translation\Plugin\Validation\Constraint\ContentTranslationSynchronizedFieldsConstraintValidator-&gt;validate(Object, Object) (Line: 185)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator-&gt;validateConstraints(Object, &#039;00000000363713070000000020a8e45f&#039;, Array) (Line: 140)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator-&gt;validateNode(Object, Array, 1) (Line: 99)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator-&gt;validate(Object, NULL, NULL) (Line: 90)
Drupal\Core\TypedData\Validation\RecursiveValidator-&gt;validate(Object) (Line: 135)
Drupal\Core\TypedData\TypedData-&gt;validate() (Line: 482)
Drupal\Core\Entity\ContentEntityBase-&gt;validate() (Line: 189)
Drupal\Core\Entity\ContentEntityForm-&gt;validateForm(Array, Object)
call_user_func_array(Array, Array) (Line: 83)
Drupal\Core\Form\FormValidator-&gt;executeValidateHandlers(Array, Object) (Line: 276)
Drupal\Core\Form\FormValidator-&gt;doValidateForm(Array, Object, &#039;node_career_opportunities_edit_form&#039;) (Line: 119)
Drupal\Core\Form\FormValidator-&gt;validateForm(&#039;node_career_opportunities_edit_form&#039;, Array, Object) (Line: 575)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;node_career_opportunities_edit_form&#039;, Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder-&gt;buildForm(&#039;node_career_opportunities_edit_form&#039;, Object) (Line: 74)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 666)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

Clarifying the steps to reproduce, this took me a while to figure out. Can confirm this still happens in HEAD.

Grooming the issue summary a bit, truncating some of the backtrace.

Updating the title to be more specific about the root cause of this issue.

Here are some tests that a) reproduce exactly what was described in the original issue and also the additional problems identified around content moderation assuming a language is always being added. I think both are valuable even if I think the fix for these will be the same because they fail in different ways: testModerationWithSpecialLanguages fails because adding a new locked language doesn't work and testChangingContentLangcode fails because of additional assertions around the need to change the CMS entity langcode instead of adding a new one.

Attempted fix for this.

The patch did not work for me on 8.5.3. Even without content moderation installed, changing the language on a node throws this error.
Invalid translation language (und) specified. in Drupal\Core\Entity\ContentEntityBase->getTranslation() (line 866 of core/lib/Drupal/Core/Entity/ContentEntityBase.php).

This patch does not seem to apply on 8.5.3. Can you test this against the latest version of 8.7.x. I also can't reproduce the issue with the patch applied based on the steps in the issue summary, can you provide some updated steps which trigger this?

I was having an issue where a node that was originally created as "- Not specified -" couldn't be assigned to a language. The error in watchdog was InvalidArgumentException: The entity cannot be translated since it is language neutral (und). in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 872 of [...]docroot/core/lib/Drupal/Core/Entity/ContentEntityBase.php).

With this patch applied to 8.4.8 (working in a distro that is behind the update curve) I can now assign nodes to a language or change them to unspecified. Note, on this older version of Drupal, the patch only applies to EntityOperations.php, it fails to apply to ContentModerationStateTest.php, but this works as a good enough stop-gap for me until the distro is able to update core.

@mattshoaf that info is very helpful, thanks. So, waiting for an update from @awm re: #19/#20.

in my case, I narrowed down the problem to the "validate" method in ContentTranslationSynchronizedFieldsConstraintValidator.php,

    if ($entity->isDefaultRevision() && !$entity->isDefaultTranslationAffectedOnly()) {
      return;
    }

entity->isDefaultTranslationAffectedOnly is returning false because it has this condition:

return !empty($bundle_info[$bundle_name]['untranslatable_fields.default_translation_affected']); 

To fix my issue, I unchecked "Hide non translatable fields on translation forms" for the content types at "admin/config/regional/content-language".
Alternatively you could use this: https://www.drupal.org/node/2938191.

That said, I am not sure why setting $entity->isDefaultTranslationAffectedOnly() is relying on

$bundle_info[$bundle_name]['untranslatable_fields.default_translation_affected']

@Sam, the patch did not work for me on 8.3. and 8.3 7 clean drush install after adding 2 languages, enabling editorial workflow for article then trying to change the language on an article.
I am attaching a db of 8.7 that you could look into.

I am attaching my attempted patch.

@awm it sounds like you're having a problem different to the one in the issue summary. Could you confirm and if that is the case open up a new issue describing steps to reproduce it?

steps to reproduce are
0. Clean site install of 8.7
1. adding 2 languages.
2.enabling editorial workflow for article
3. add an article
4. change the language of the article.

This result in the error posted above. I believe it's the same issue.

Update this is the error I am getting:

The website encountered an unexpected error. Please try again later.InvalidArgumentException: Invalid translation language (und) specified. in Drupal\Core\Entity\ContentEntityBase->getTranslation() (line 872 of core/lib/Drupal/Core/Entity/ContentEntityBase.php).

I could open a new issue for this.

I am creating a new issue for what I am seeing which is not related to content moderation I believe.

Here is the new issue https://www.drupal.org/project/drupal/issues/2995655

Adding patch for Drupal 8.5.x

@awm, thanks for clarifying and opening the follow-up. Reuploading #15 with NR status.

The patch makes perfect sense, and the test coverage looks great!

+++ b/core/modules/content_moderation/tests/src/Kernel/ContentModerationStateTest.php
@@ -416,25 +416,78 @@ public function testModerationWithFieldConfigOverride() {
+    $this->assertEquals(count($entity->getTranslationLanguages()), count($content_moderation_state->getTranslationLanguages()));
...
+    $this->assertEquals(count($entity->getTranslationLanguages()), count($content_moderation_state->getTranslationLanguages()));

Can we also assert that the count is 1? ;)

Okay, good point, I like this a lot better :)

#33 is addressed so back to RTBC.

Fixing linting issues.

Let's try again.

Way better!

Saving credits

Committed dd57111 and pushed to 8.7.x. Thanks!

This was not backported to 8.6.x yet.

Now it is :)

Ah indeed! Thanks for sorting that.

Looks like this can result in exceptions, see #3024816: EntityOperations::updateOrCreateFromEntity(): A translation already exists for the specified language.