Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
We updated the patch to has a config checkbox "Allow translated Paragraphs".
Setting up:
- Apply the patch to the Paragraphs module (in composer.json)
- Configuration -> Paragraphs Settings (/admin/config/content/paragraphs) -> Check the "Allow translated Paragraphs"
- Paragraph type -> Manage form display -> Paragraph Field -> "Paragraph EXPERIMENTAL" (instead of "Paragraphs Classic")
Tested on both 1.x-dev and 1.5.0 versions.
Comment | File | Size | Author |
---|---|---|---|
#46 | 2924774-46.patch | 2.32 KB | vuil |
#29 | 2924774-29.patch | 1.3 KB | Rajab Natshah |
| |||
#24 | 2924774-24.patch | 817 bytes | Rajab Natshah |
#10 | Content--dev--drupal842c.png | 17.61 KB | Rajab Natshah |
#4 | 2924774-4.patch | 1.37 KB | Rajab Natshah |
Comments
Comment #2
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #3
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #4
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedFirst Draft test patch
Comment #5
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #6
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #7
miro_dietikerI agree that the current situation is unfortunate:
I sometimes want to edit the source / structure and accidentally end up on a translation and i‘m searching for these buttons as well...
Note that some related structural actions are accidentally still visible while translating. There are pending issues that will hide even more actions.
The origin of the problem IMHO is that Drupal core does list translation records in admin/content and it is unclear what is source and what a translation. The node header title explains it, but much unreadable.
We could offer a global setting to still display ALL the actions even if we are translating.. IMHO we should improve the consistency and UX of the strict separation of these two processes (also in core). Once this is better established, hiding these links is what everyone expects (except to manage language specific paragraphs in a translatable ERR field scenario).
Comment #9
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedThank you Miro,
Paragraphs is an innovative module and your work on it is very much appreciated.
I have a question about the settings:
Which one do you like to experiment with first?
Comment #10
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedNoted for the Drupal Core issue, Thank you.
With you on that, it could be with a number of tab links for each language to auto filter and have some kind of referral or flag for the node which will look like it says [T] "I'm a translation for ( the original title and link )"
This could be in core or a custom module which could be named multilingual content tabs, or advanced multilingual options
I will move in the direction which you like us to experiment with.
Comment #11
miro_dietikerI provided a new parent issue around this topic of hiding shared actions.
#2932344: [META] Hide shared actions when translating
This issue is now first only about extend the method of allowReferenceChanges() with the setting.
We want to support such a special case as a HIDDEN global setting.
So it would be a variable you set via drush cset.
We don't want to add many more settings to the Paragraphs field widget UI. And we want to avoid a global settings UI.
However still, you need to extend multilingual tests to check the setting effect and once interact with these features in translation perspective after enabling it.
Comment #12
miro_dietikerWe progressed quite well with hiding buttons. Only drag & drop (button + handles in table) missing and will completed likely soon.
Let's see if more people want an option to get the buttons back while translating.
In any case, a good time to restart implementation.
Comment #13
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #14
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedHappy with that Miro!
#2909416: Hide duplicate action while translating
"Issue #2909416: Hide duplicate action while translating.": "https://www.drupal.org/files/issues/2909416-2.patch",
If we jump to "drupal/paragraphs": "1.x-dev#5d8ca4e"
HIDDEN global setting
Drush, or Console commands to set the config value
switches:
Sample config will do at this time
paragraphs.settings.yml
A Better Sample config format could be proposed
paragraphs.settings.yml
or
paragraphs.behaviors.yml
If we do not have a space for a basic General paragraphs setting page. a router path: admin/config/paragraphs, we could mange that in a custom module paragraphs_settings, paragraphs_config_ui.
Having the switch of basic settings included in the code to change the behavior by the switch will help very much.
Comment #15
miro_dietikerFor the field management UI of Paragraphs Library, we just added an empty settings page.
That will be moved into Paragraphs very soon... We either can the provide a Paragraphs settings page and let the library extend that or add a separate such page for Paragraphs.
We usually don't add too many switches...
IMHO if i can add a Paragraph in the UI, i also want to be able to remove it again.
More variations seem to cause more user confusion: "Why is button X missing here and not there?"
As linked above, Thunder people also asked to easily disable the cloning. That's a candidate for a global setting.. or put into the widget again.. Still, if i allow duplication, i would want to have it consistently enabled only when editing the source, or while translating - if actions are allowed there.
I don't see how the settings granularity is allowing any value for a use case i know of.
And if a custom project needs custom visibility, we can still alter the form.
We already implemented an API where the settings need to be checked and you're done.:
Also why do we need a new command if we can use the settings command?
I really don't feel like maintaining more complexity in Paragraphs.
Comment #16
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedGood then. Got that
I think a simple settings in the config/install/ file will do it for now.
paragraphs.settings.yml
I think the issue is for
Change of an action based on when or where in the code.
I think we should only allow When [Editing a translation] ..
not while we are translating and not translated content.
I have updated the description for this issue with:
Comment #17
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #18
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #19
sgurlt CreditAttribution: sgurlt commentedThanks a lot for working on this :)
I totally agree with the current approach and really looking forward to be able to test that.
Question:
What will happen when a translation for a node already exists and a paragraph is added to the main language?
I am asking because for our latest project we had to find a quick solution for that and we build a submodule for paragraphs:
https://www.drupal.org/node/2887353
The submodule uses the current implementation of paragraphs where you can not add paragraphs to translations. Additionally when a paragraph is added to the main language, the paragraph is also created within all translations but is marked as "unpublished" since we wanted to give our editors the chance to review the new content and add a translation for it :)
Maybe this also helps with this issue.
Comment #20
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commented#2924064: [Suggestion] Sync new paragraphs button to sync not translated paragraphs
#2887353: Paragraph Translation Sync
We all are trying to do the same thing :) , which could help us move on in our projects.
I like the idea of having sub modules to change the behavior, By having the sync function as a button, we could have the paragraph field as translatable or not translatable.
Or we could go and have a function "Clone paragraphs from other entities" ...
so that when we translate the the entity, the paragraph field could stay not translatable, but we could clone paragraphs from other nodes for example.
I'm looking at the direction which Miro want to move to.
By time I'm getting what Miro is talking about.
Looking foreword into understanding the full picture.
Comment #21
miro_dietikerThis issue should stay minimal and not deal with the async translation topics.
The plan was to just unhide the buttons for the synchronous case that then leads to the default functionality where a new Paragraph with published status is added for all languages.
Thus it‘s not changing functionality, it‘s more setting what you expect as UX consistency. Core also still has recent issues if shared fields in content moderation should be hidden or displayed. The „all languages“ thing is a UX mess...
Comment #22
miro_dietikerI think the code snippet „&&“ is wrong snd should be:
return !$this->isTranslating || \Drupal::configFactory()->getEditable('paragraphs.settings')->get('allow_reference_changes');
I think if i should be able to add a Paragraph thile translating then i should be able to do so while adding a translation or editing one. Why make a difference between adding and editing?
Comment #23
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedNoted Miro,
Your logic is better than mine, as you do have the full picture of UI/UX and the code :)
I have attached a patch file with your latest logic.
Planing a full UPDATE test on sites with the latest paragraph dev progress.
Comment #24
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #25
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #26
miro_dietikerConfig needs a schema or things break hard. And we need a test scenario with this setting enabled.
Comment #27
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #28
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #29
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedI have updated the patch to work Paragraphs 8.1.3
Comment #30
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #31
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #32
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #33
miro_dietikerThis needs some extra test.
I also see that this setting will likely conflict when content moderation is on. We likely will postpone it for the content moderation fix and will also need a combined test.
Comment #34
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #35
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #36
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #37
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #38
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #39
robpowell@miro_dietiker Is this the content moderation issue this task is now dependent on, https://www.drupal.org/project/paragraphs/issues/2951436?
Also, what testing covering needs to be added? Can this be done in parallel or needs to wait till 2951436 lands?
Comment #40
miro_dietiker@robpowell yeah this as a starting point, but i can't tell you exactly how much we're blocked.
The parent meta to support Content Moderation is #2807371: META Support Content Moderation module
More notes about prioritisation and preferred sequence is maintained at the #2954487: New Roadmap
You can always proceed with writing tests.
We have test coverage that checks that these elements are hidden while translating.
Not sure yet, either extend existing user stories with altering the setting and check it appears or put a new test / user story that tests all steps with the setting on.
Tests will help to review compatibility with Content Moderation.
Comment #41
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #42
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commented@miro_dietiker Noted
Thank you for your review.
I have updated the Issue summary after your last comment yesterday.
Remaining tasks
Is it OK to go with the following testing
Scenario: Check if "Site Editors" can add more/delete paragraphs entities in an already translated content in multilingual sites.
Comment #43
miro_dietikerIf we allow structural changes later when editing a translation, why would you want to disallow this when adding a translation?
Comment #44
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedI'm with that too. I'm only following your vision for what is best behaver.
It could load like a Clone for the node .. But It's a translation
We talked about that in #14
switches:
Then they become one allow_reference_changes
Not sure where in the code it will do [allow while translating] .. But I think [allow after translating]
as in
return !$this->isTranslating || \Drupal::configFactory()->getEditable('paragraphs.settings')->get('allow_reference_changes');
or just the following:
return \Drupal::configFactory()->getEditable('paragraphs.settings')->get('allow_reference_changes');
I have got that Content Moderation is one important key , revision is important too
When we do have some Site Builders or Editors
Which they could have 50 content pages with some 10 or 20 paragraphs in each page.
Editors may think that we Translate first then do some changes.
( Clone, sync, translating the text )
Which revision will be linked as a translation at the time of translation?
Our issue when we do not set the paragraph field as translatable field is redoing 50 pages with 10 or 20 paragraphs each.
at this point we can talk about the sync option between translated pages for example or sync option from other pages. ( Clone do that ) But in (Translation we can not do that)
#2924064: [Suggestion] Sync new paragraphs button to sync not translated paragraphs
I'm looking at tests in the paragraph module to code the testing scenarios with
Following your standard on testing.
I LOVE Open source and the collaborative work.
If you switch the logic of scenarios I will switch with you on that.
Comment #45
caspervoogt CreditAttribution: caspervoogt at Plethora commentedI think I am encountering the same issue, but am not 100% sure. In my scenario I have an English node which contains a paragraph of four items (using Bootstrap Paragraphs in my case). I then translate that to French, so the French version also has four columns. I can edit the contents of those columns in French, and that works. However, if I add a fifth column to the English node, the French translation does not get a fifth node, and there is no way to add a fifth column to that paragraph.
I did try the patch from #29, but it made no difference.
Comment #46
vuilWe updated the patch to has a config checkbox "Allow translated Paragraphs".
Setting up:
Tested on both 1.x-dev and 1.5.0 versions.
Comment #47
vuilComment #48
miro_dietikerThis feature is definitively incompatible with multilingual content moderation in our current implementation.
Comment #49
BerdirWhat Miro means is basically \entity_reference_revisions_entity_revision_create(), which ensures that it is possible to create drafts in different translations which are then merged again when being published. The only way that is possible is that the structure is fixed and can't be changed, otherwise those changes would be ignored/dropped again.
I don't see a way to bring those two things together and as a result, don't think this patch can be committed. Just like core requires now when using content moderation that untranslatable fields are hidden, we must disallow any changes that could later on result in data lass when "merging".
Comment #50
vuilComment #51
vuilComment #52
GiorgosKComment #53
GiorgosKSo based on the last comments from Miro and Berdir this should be marked as closed works as designed or similar but I can't seem to be able to change the status