Close paragraphs without translatable fields while translating

+++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
@@ -464,6 +464,28 @@ class ParagraphsWidget extends WidgetBase {
+      foreach (array_keys($display->get('content')) as $field) {
...
+      if ($this->isTranslating && $translating_closed && !isset($widget_state['paragraphs'][$delta]['mode'])) {

Really only do this loop and all this complexity if we are translating and it is until now considered open.
If we have such a force-closed Paragraph, we should maybe also hide the edit button as there's nothing you can do anyway.
If i'm wrong, we can always revert this direction...

Maybe we should look at this combined with the other requirement to always expand Paragraphs when adding a translation.
#2954921: Expand all Paragraphs recursively when adding a translation

There will be more to consider as unpublished paragraph translations could indicate that a translation is not yet ready, so expansion still makes sense on later edits. However it would be not if the semantic of an unpublished paragraph translation means it should persistently be hidden for that language. That's why we need to define how to deal with this.

Realizing that combining is boosting complexity and slowing us down and we maybe should go step by step.
So let's stay limited here, but include the hiding of the edit button.

Then we can do a UX assessment on real content instances to figure out if it creates frictions.

There's one thing we shouldn't forget:
If you don't have content moderation enabled, you can easily have untranslatable fields displayed when translating.
If someone prefers this flavor of editing everyting that is visible on the translation rendering on one page, we can not force close and hide.
Not sure where core goes, but we should only force collapse if fields are configured to be hidden.

So we need to check the setting at admin/config/regional/content-language for the content type in question: "Hide non translatable fields on translation forms"

+++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
@@ -464,6 +464,36 @@ class ParagraphsWidget extends WidgetBase {
+      $translating_open = TRUE;
...
+        $translating_open = FALSE;

@@ -600,7 +630,7 @@ class ParagraphsWidget extends WidgetBase {
+              '#access' => $paragraphs_entity->access('update') && $translating_open,

That's a super strange name and IMHO the logic is inverted.

We want a variable $translating_force_close = FALSE -- maiby just $force_close -- initially that is set to TRUE if expanding is not allowed anymore.

Then below its && !$force_close;

It's simply weird otherwise if we have a variable "translating_open" that is set to TRUE if we are not translating at all...

Soo i see we have a bunch of fails? ;-)

Looks awesome. Some nitpick below..

+++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
@@ -464,6 +464,38 @@ class ParagraphsWidget extends WidgetBase {
+                  $translating_force_close = FALSE;
...
+                $translating_force_close = FALSE;

We can quit the loop with break on the first match here.
Rewriting a bit blindly.

Awesome, committing this. :-)

This is nice, but it might not be 100% obvious to users *why* they can't do anything with those paragraphs. Maybe we could use the free space to show some sort of notice that this paragraph can not be expanded because there's nothing to translate?

Created follow-up #3009913: Indicate why a Paragraph without translatable fields is force collapsed