This entity (file: XXX) cannot be referenced when editing translated node with other user

Is the paragraphs ERR field (on the parten / host entity) itself accidentally marked as translatable?
Or is the image field translatable?
How is the language negotiation setup? Do you have different content / interface language negotiations?

Check your selection handler and settings (on the field configuration).
It would help if you could tell us a bit more about that setup. Maybe you want to reproduce the issue in a completely new environment to figure out what is needed to make it repeatable?

I was having the same issue. In a content type, I have a paragraph field that is used to choose between different layouts. The first level is then only containing non translatable fields (column count, background color, etc.) and another paragraph fields, that will store the subitms. That paragraph type (two level down) contains translatable fields.

In translation configuration, as the first level paragraph as no translatable fields, it remained as not translatable. Only second level paragraph type was translatable. But this configuration seems to break the translatable information down the way. If I just add a translatable field on the first level paragraph, the second level is then working as expected.

Uhh that's unfortunate. But this confuses me as containers are a common scenario and in most cases those containers have an untranslatable Paragraphs field while childrens then are again translatable. I still feel like the amount of information here doesn't allow us to reproduce the issue..

@plurial Does this workaround with a translatable field also work if you then hide that field from the form?

Best case is if someone who experience the issue provides a test.

Hi,

We got this same error, and had some trouble tracking it down, but it turned out to be completely unrelated. The problem in our case was we had added a paragraph to a node using a paragraph type from "bootstrap paragraphs" module, a carousel. And then at some point that type got unchecked in the field definition for the paragraph field. And then you could no longer edit this node -- because it had a carousel paragraph already, but that was not a valid type.

Could this be the original poster's issue?

In any case, the error message does not help identify the source of the problem...

I came here because this issue came up when Googling the same error message. In my case, I see this when trying to add a translation to a media entity, where I'm at this url:

/en/media/68/translations/add/sv/en

So I think the problem is outside of Paragraphs.

Unpostponing here at least to cover the case where a paragraph type is disallowed.

We need to be nice or manage such a situation. It's likely that a Paragraph type is still used and then unselected.
While editing, we need to make it clear where the unsupported element is.

My setup where I am able to reproduce the issue and really looking for a solution:

* There are two languages (EN and AR) enabled
* Content Moderation is enabled
* I have a paragraph field in node (translation enabled for node, disabled for the field)
* That paragraph field contains another paragraph field (translation enabled for the field here as without that I'm not able to add translations)
* Second level paragraph contains two fields (Image and Link), both of them have translations enabled

Everything seems working fine when adding/editing content for EN
Everything works fine for adding translations on AR
When I go to update the images after saving once without changing moderation state, it saves the files with status 0 and no entry in usage table, I tried to debug and I can see delete() is called in core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php::invokeFieldMethod for $method: 'postSave', still trying to figure out why it is not having proper translations in $entity here and $entity->original contains translation for both languages.

This is resulting into two issues, one mentioned above (when trying to edit this node as second user since the file is having status = 0, it is not allowing to reference) and file is deleted during garbage collection in file_cron.

Mind that we officially don't support Content moderation yet: #2807371: META Support Content Moderation module
Thus it's more a duplicate of that feature request...

Can you check and report if the issues also apply without content moderation? If yes, then it is a major+ bug.

Reproduced the issue even without content moderation.

Want to highlight again a few things:

* Issue is coming for second level paragraphs where translation is enabled for paragraph field in first level
* Without enabling translation in first level paragraph field for paragraph entity - translations don't work

Uhm, the top level paragraphs field is marked as translatable?
Checkout this issue: #2461695: Support asymmetric translations
Translatable ERR fields are currently not supported by Paragraphs. Maybe duplicate?

I just did that check too, I removed translation from both levels (it was translatable in second level previously) and still issue existed

Config:

Node (translation enabled):
--Paragraph A (field not translatable)
----Paragraph AB (field in A, field translatable before, not in the last test)
------Image field (inside field Paragraph AB, field translatable)

On my fresh tests, I was able to get translation working even after setting translatable setting to false in Paragraph AB with new content but still the issue exists :(

Just did a quick test on fresh install with proper configurations from start and no content moderation module, it works fine

http://dev.nik4u.com/node/1
http://dev.nik4u.com/ar/node/1

I modified multiple times and it stored proper status (status 1) in file_usage and entry in file_managed.

I'm still not sure about marking this as duplicate as original scenario mentioned above might be different.

It seems updated translation settings (allowing paragraph translations) in https://www.drupal.org/node/2461695 fixes my use case and everything seems working fine with that.