Problem/Motivation
When adding translations to a node, "direct" fields, i.e. no paragraphs, get their translation added instantly, whereas paragraphs only get their translations added upon clicking "edit" for the respective paragraph.
Proposed resolution
If automated translations become perfect one day, it would be nice to only have to view the whole node in its translated version without having to click "edit" for every single paragraph (and their nested paragraphs, etc.) first.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | Screenshot 2025-03-12 at 14.49.08.png | 227.63 KB | bigbabert |
| #5 | 2025-03-11_081046_screenshot.png | 120.66 KB | tgoeg |
| #3 | 2025-03-10_144416_screenshot.png | 71.78 KB | tgoeg |
Comments
Comment #2
bigbabertHi @tgoeg,
this could be related to paragrpahs edit form settings, could you share more detail about the configuration of the collapsed paragraph form view?
Best regards
Comment #3
tgoeg commentedThis is a config I took over, so I don't know the exact details of why it is configured like this. "Legacy" sounds ... outdated :-)
Maybe it's just that the "stable" mode has not been available back then?
This is how it looks like:

Title: Paragraph
Plural title: Paragraphs
Edit mode: Open
Add mode: Dropdown button
Form display mode: default
If I change the widget to "Paragraphs (stable)" and/or the "Edit mode: Closed, show nested", I see the same problem.
Would I have to create a specific "Form display mode" ?
Comment #4
bigbabertHi @tgoeg,
have you also tried latest version? in my tests with both configurations, stable and legacy, when i open the add translation form all the paragraphs come opened (uncollapsed) with all the fields translated, and i've tested with like 20 paragraphs with nested paragraphs inside (eg. carousel with slides etc.).
Best regards
Comment #5
tgoeg commentedJust tried with 1.3.7, no change.
By uncollapsed, do you mean they are already editable? I have an "edit" button next to each paragraph:
If I click it, the translation gets triggered and works as it should.
I use the "seven" admin theme, tried claro now as well, that didn't seem to make a difference.
I searched quite a bit now, but I seems you always have to click edit to start editing a paragraph, this does not seem to be configurable?
Do you already see translations *before* clicking the edit button?
Comment #6
bigbabertHi @ tgoeg,
yes i see translations before clicking on edit, below screenshot of my child paragraphs form settings inside the parent paragraph.
BR
Comment #7
tgoeg commentedThat does not seems to differ from my setup here, strange.
I see another effect, maybe this is related as well?
When I click edit on one paragraph and trigger the translation but not on another one and save the article, I cannot make auto translation work anymore, i.e. the next time I edit the article. Paragraphs just stay in their original language.
But that's probably expected as that should not happen in the first place as your setup would never leave you with untranslated paragraphs.
I just thought I'd note this down as it might ring a bell for you.
I'm still on Drupal 10.3.x, but just tried with an updated instance on 10.4.x, same story.
Are you on 11 already?
I'm somehow running out of ideas where to debug further.
We might need deepl.com translations so I am considering to take a look at tmgmt but find the problem here would have been nice, still.
Comment #8
bigbabertHi @tgoeg,
added new features like bulk translations, block content, taxonomy and media translations and also DeepL API translation support.
Also minor fixes to prevent unwanted fields settings translation, check it out!
Best regards
Comment #9
bigbabertComment #10
bigbabertComment #11
tgoeg commentedTested the newest 1.4.21, did a drush updb and drush cr, but I still don't have translations for nested paragraphs.
I'll try to debug this, but bear with me, I am not a proper developer!
If I change the following in ./src/Utility.php:
The log states:
field_accordion_list_content is a reference to paragraphswhich is expected.
However, the var_dump($form) gives me:
$form[$field_name] is therefore not set.
Does this ring a bell for you?
Comment #12
tgoeg commentedComment #13
tgoeg commentedAdded more logging, the function now looks like this:
And the output, if I click "Add translation":
Note how "subform is not set for nested paragraph".
If I click the edit button of a paragraph in the node edit form that's now open:
Now the "Subform is set".
I switched to the Bartik theme on the frontend now as well, to rule out possible hooks messing with the form, to no avail.
Is it possible to force load this form somehow? It does not seem to be populated the moment I need it, only later.
Apart from that, I think there should be an else-branch (with the reference-to-a-paragraph code) when detecting whether we have a widget. It can't be both, I guess?
Comment #14
bigbabertHi @tgoeg,
Thanks for the feedback, this looks as a really specific use case, if any other will report same issue i'll evaluate.
The module is tested and work with Gin Admin Theme from Drupal 10 to drupal 11.
Best regards
Comment #15
tgoeg commentedIf I use the bulk translation option, all nested paragraphs do get successfully translated, so this really seems to be very related to the way the form gets created when editing a node manually.
This somehow seems to say that my configuration should not be too far off, right?
I'll try to reduce the test case.
Or could you maybe provide a working config export so I can see what differs to my setup?
Comment #16
bigbabertHi @tgoeg,
sorry for the late answer, i've tested with fresh installation of drupal CMS added some 2 paragraph configured as Not Translatable with fields inside configured as Transletable.
I'll provide you a working config as soon i'll be able,
Best regards
Alberto
Comment #17
tgoeg commentedOh man, this took me too long.
I finally figured it out.
For the subform to exist, it needs to be open right from the start (just as you said).
However, there are multiple places where this has to be configured.
I only set it in the paragraph settings itself (and all nested paragraphs below it) at
/admin/structure/paragraphs_type/accordion_list_entry/form-display.But it also has to be set at the top level, i.e. the basic page or article form display, i.e.
/admin/structure/types/manage/page/form-displayor/admin/structure/types/manage/article/form-displayor whatever the used content type is.This either needs to be part of the manual/usage instructions or a hook should be implemented that force opens the widgets ($form[$field_name]['#paragraphs_edit_mode'] = 'open'), as this an expected state before this module can even operate on nested paragraphs.
I had no luck implementing this, so I resorted to configuring the paragraphs to be always in "open" mode in the backend.
Comment #18
bigbabertHi @tgoeg,
glad that you had chance to figure out the right configurations!
And also thanks for precious inputs as always :) i will look into that in the weekend, hopefully will be easy to implement logic to check and force widgets to be open :)
Thanks again
Comment #19
bigbabertHi @tgoeg,
i'm still not able to reproduce the issue below paragraph reference field on my node and if i open the translate form the fields are correctly translated with also the html markup.
Title: Paragraph
Plural title: Paragraphs
Edit mode: Closed
Closed mode: Preview
Autocollapse: All
Closed mode threshold: 3
Add mode: Dropdown button
Form display mode: default
Default paragraph type: Test Paragraphs
Features: Duplicate
Please test with latest paragraph module or indicate what version are you using so i can try to reproduce it.
Best regards
Comment #20
tgoeg commentedI'm on Drupal 10.3.14 (latest 10.3), Paragraphs 8.x-1.19 (latest)
I have a (content type) page.
On this "page", I have a field_paragraph that is a reference to other paragraphs (one of them an accordion). This field_paragraph had its widget configured as "closed".
In the paragraph config, the accordion paragraph did indeed have its widget configured as "open".
Only when I reconfigured the top-level paragraph, i.e. the one in the "page", to be "open", I saw all (nested) paragraphs in an editable state as soon as I started editing the "page".
Are your (nested) paragraphs editable when you edit an existing node or do you have an edit button that, upon clicking, opens the widget, CKEditor, etc. ?
You need this (top-level?) closed state to reproduce the issue.