Non-translatable fields can only be changed when updating the current revision.

Patch does not apply on version 1.1x of this module.
Drupal 9.5.2

Patch on #2 works like a charm!

Drupal: 9.5.2
Entity Reference Revision: 8.x-1.10

Patch #2 works for me also

Drupal core 9.5.2
Entity Reference Revisions 8.x-1.10

Drupal 9.5.5 - Patch #2 did not work for me. We have a content type with multiple paragraph fields, and these fields have entity reference revisions. Some of these paragraphs contain other paragraph fields.

I found the problem is fixed by going through every field in the revisions and making sure to check the box "Users my translate this field". I did this even though there is the warning about how paragraphs do not support translations. This fixed the error and at least now I can update the content. Otherwise the nodes are stuck & cannot be updated (in any field).

Thanks patch #2 works well for me in D9.5.9

For the comment in #30 by @wheelercreek by ticking your paragraphs as translatable you might run into this issue:

1) You have a node in EN and DE
2) You have a node with a paragraph with 5 items
3) Delete 1 of the paragraphs in EN
4) Go and translate DE and you'll see the deleted paragraph is visible and you have no way to delete it from the translation

Re #31 I think the right and safe way would be to make the "published" field translatable and simply set it unpublished in languages where you don't need it (for sync translation)

Patch #2 worked for me!

Drupal version: 10.1.4
Entity Reference Revision version: 1.10

Thanks!

Patch #2 worked for me as well.

Drupal version: 10.1.4
Entity Reference Revision version: 1.10

Re-roll for 1.11

Patch #35 worked in conjunction with checking "Hide non translatable fields on translation forms" on the relevant paragraph(s).

Patch #35 for 1.11 applied on d10.2.3. thank you.

Patch #35 for 1.11 applied on d10.2.3. as well and fixes my problem.

Hi, yes, I can confirm that Patch #35 worked in conjunction with checking "Hide non translatable fields on translation forms" on the relevant paragraph(s). It did not work without the "Hide non translatable fields on translation forms" enabled, as I'd get the red errors under all the fields.

Entity Reference Revision 1.11.0
Paragraphs: 1.17.0
Drupal: 10.2.5

+1

This needs to be a merge request to run against current tests.

Still here on 10.3.2. "Hide non translatable fields on translation forms" enabled.

I have updated the MR to represent the changes from #35 → .

I am still trying to understand though... I was able to fix the problem in my case without this patch; with the Hide non translatable fields on translation forms enabled. So, my question is, does this fix the whole problem? Or just a portion of it?

I am facing almost similar issue - can not add any new field to any content type:

he website encountered an unexpected error. Try again later.

TypeError: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 45 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Drupal\Core\Plugin\DefaultPluginManager->getDefinition() (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 76)
Drupal\Component\Plugin\PluginManagerBase->createInstance() (Line: 136)
Drupal\field_ui\Form\FieldStorageAddForm->processFieldDefinitions() (Line: 80)
Drupal\field_ui\Form\FieldStorageAddForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

The patch #2 has been updated to fix the issue with taxonomy terms.
Steps to reproduce:
1. Enable content moderation and set up the following moderation states: Draft, Awaiting Approval, and Published.
2. Enable workflow for the taxonomy.
3. Create a taxonomy term.
4. Create a translation for that term.
5. Edit the original entity and add an additional paragraph to the `entity_reference_revisions` field.
6. Save the entity as a draft.
7. Edit your translation; you will notice that the newly added paragraph does not appear in the specified field.

Few quick updates:

1. Hid patches since we have a merge request (Download patches locally per drupal.org guides if you need)
2. Suggest we don't do the scope creep of #47 and that gets raised as a separate issue
3. Needs work since this needs tests still as per #5

Test coverage:

I had a look at test coverage and its challenging; I believe in EntityReferenceRevisionsCompositeTranslationTest.php we need to check that the nested new revision updated in entity_reference_revisions_entity_revision_create is set to the default revision (where it is meant to be) yet currently is not default revision by directly calling that method. Otherwise this bit from the issue summary will continue to kick in and therefore mask the problem:

ModerationStateFieldItemList::setValue calls updateModeratedEntity which resets the node to default revision if the moderate state is such

Regarding this from the issue summary:

Decide whether this is correct. Maybe not for the generic case and then it needs to be somehow restricted to paragraphs. I do not know how to do that.

I tested out IEF including enabling the sub-modules with the MR here applied. I ran its test coverage for translation which passes fine and did a manual pass at attempting translations. So it appears IEF continues to work fine with this MR in place.

Okay this is ready for review again. There is now automated test coverage testing that function. I needed to test in isolation as per reasoning in #48.

If someone from the community could have a quick check to get this back to RTBC would be much appreciated.

Its an issue I keep stumbling across over the years so figured its worth the time trying to push this forward to save future us some time scratching our heads again :)