- use a paragraph field on a content type with translation support and with the language widget enabled.
- go to the add content form
- change the language of the new content (let's say from English to German)
- click on the button to add a paragraph
The result should be that the paragraph form elements appear, but not the "Remove" and the Add other paragraph buttons, so basically you are stuck with those form elements. If you do not change the language in the workflow above, then it works.
The access to those buttons seems to be checked in src/Plugin/Field/FieldWidget/InlineParagraphWidget.php on line 299. As a temporary solution in our projects, we just used this:
$button_access = $paragraphs_entity->access('delete');
but most probably there has to be a better way of fixing the issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | buttons_to_remove_and-2669732-22.patch | 3.64 KB | tduong |
| #22 | buttons_to_remove_and-2669732-22-test_only.patch | 1.16 KB | tduong |
| #22 | interdiff-2669732-15-22.txt | 911 bytes | tduong |
| #15 | add more and remove buttons.png | 110.34 KB | tduong |
| #11 | buttons_to_remove_and-2669732-11.patch | 855 bytes | johnchque |
Comments
Comment #2
miro_dietikerNice catch. Indeed.
It means when i create a new node with a non-default source language, the paragraph widget does not allow adding more paragraphs.
Comment #3
vasi1186 commentedExactly, because the language of the paragraph entity is different than the language of the untranslated paragraph entity, but this should not be the case, because the untranslated paragraph entity should be the same as the original one in my opinion.
Comment #4
progzy commentedI have a similar problem when translating a node to another language ; no "remove" and "add" buttons.
I've then replaced the code for "$button_access" with the one above ("remove" button) + set "$add_more_access" ("add" button) to TRUE (line 735).
Is there any reasons that the code was designed this way? Is there any drawbacks (could it break something?) to show them as I did above?
Comment #5
miro_dietiker@progzy that was discussed and buttons are hidden by design, also to avoid pitfalls.
If a translator would remove a paragraph, it would get removed for all languages!
If you translate, you should translate. A translation means having the same structure of information in a different language.
Alternatively you need this major feature implemented: #2461695: Support asymmetric translations
Comment #6
progzy commentedMy field is declared as translatable and this is not the case ; I can remove paragraphs independently.
Probably but if one adds a paragraph for source language "A" to an existing and already translated node it won't be reflected on language B and it won't be possible to add it since button is hidden.
Comment #7
miro_dietiker@progzy We currently do NOT support translatable paragraph fields. See #2461695: Support asymmetric translations
That case is unrelated to this issue!
Comment #8
progzy commented@miro_dietiker ok I think I understand now, thank you, my bad.
PS: However if I understand well I think a sentence from the "read me" is confusing. I've just created the following issue to clarify that point (and stop polluting this issue with none-related content) : https://www.drupal.org/node/2687839
Comment #9
johnchqueComment #10
miro_dietikerWe should also investigate the situation where the source is changed for an existing entity and then an ajax action is triggered. I guess buttons now also disappear.
We need to find a much more reliable logic to detect when the user is translating.. and boost test coverage dedicated to the varying translation and / or source language change workflows.
Comment #11
johnchqueAdded tests to prove this is not working as it should.
Comment #15
tduong commentedFinally! After big discussion, attempts and final instructions from @miro_dietiker, we are able to make it work! :D
Comment #22
tduong commentedMissing additional check...
Comment #26
tduong commentedOpened a "multilingual workflow bugs only meta issue" #2698239: Multilingual workflow bugs for a "general" discussion for these kind of bugs.
Comment #27
jfeltkampPatch works fine and code is ok as far as I can see.
Thank you for fixing this issue.
Comment #28
johnchque@JFeltkamp please note that after debugging for long we realized that the last patch is not reliable, we are working on this with a colleague and we are uploading patches on the related issue #2698239: Multilingual workflow bugs. We can say after long discussions that the patches uploaded in the related issue contain the fix, we are adding tests now for covering every specific case.
Comment #29
miro_dietikerPostponing for #2698239: Multilingual workflow bugs
The issue is likely to be solved there.
Currently we need to wait for an ERR release.
Comment #30
johnchqueFixed and test covered in #2698239: Multilingual workflow bugs