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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RajabNatshah created an issue. See original summary.

Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Rajab Natshah’s picture

First Draft test patch

Rajab Natshah’s picture

Status: Active » Needs review
Rajab Natshah’s picture

Issue summary: View changes
miro_dietiker’s picture

Issue tags: +Usability

I 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).

Status: Needs review » Needs work

The last submitted patch, 4: 2924774-4.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Rajab Natshah’s picture

Thank you Miro,
Paragraphs is an innovative module and your work on it is very much appreciated.

I have a question about the settings:

  1. Paragraphs global settings
  2. Or Paragraphs field settings

Which one do you like to experiment with first?

Rajab Natshah’s picture

Issue summary: View changes
FileSize
17.61 KB

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.

Noted 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.

miro_dietiker’s picture

I 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.

miro_dietiker’s picture

Status: Needs work » Active

We 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.

Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

In any case, a good time to restart implementation.

Happy 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"

We want to support such a special case as a HIDDEN global setting.
So it would be a variable you set via drush cset.

HIDDEN global setting
Drush, or Console commands to set the config value

switches:

  • allow add paragraphs while translating
  • allow delete while translating
  • allow clone while translating
  • allow add paragraphs after translating
  • allow delete paragraphs after translating
  • allow clone paragraphs after translating

Sample config will do at this time
paragraphs.settings.yml

paragraphs_while_translating_allow_add: false
paragraphs_while_translating_allow_delete: false
paragraphs_while_translating_allow_clone: false
paragraphs_after_translating_allow_add: false
paragraphs_after_translating_allow_delete: false
paragraphs_after_translating_allow_clone: false

A Better Sample config format could be proposed
paragraphs.settings.yml

translation:
  - while:
     allow_add: false
     allow_delete: false
     allow_clone: false
  - after:
     allow_add: false
     allow_delete: false
     allow_clone: false

or

paragraphs.behaviors.yml

behaviors:
  when:
    single_language:
      allow_add: true
      allow_delete: true
      allow_clone: true
    translated:
      allow_add: true
      allow_delete: true
      allow_clone: true
    not_translated_yet:
      allow_add: false
      allow_delete: false
      allow_clone: false

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.

miro_dietiker’s picture

For 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.:

  protected function allowReferenceChanges() {
    return !$this->isTranslating;
  }

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.

Rajab Natshah’s picture

Good then. Got that

I think a simple settings in the config/install/ file will do it for now.
paragraphs.settings.yml

allow_reference_changes: false

I think the issue is for

When to allow reference changes
or when to change the value of isTranslating

Where to allow reference changes
or where to change the value of isTranslating

Change of an action based on when or where in the code.

 protected function allowReferenceChanges() {
    return !$this->isTranslating && \Drupal::configFactory()->getEditable('paragraphs.settings')->get('allow_reference_changes');
  }

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:

Given that we do have a content type "Landing Page" with paragraphs filed and number of paragraph types
When we create an English node (Default language) with number of paragraphs entities
Then the English node page will show the list of paragraphs in the Default language
When we translate the node into other languages
Then we will not be able to add/clone/delete On the first translation action
When we edit an already translated node which uses paragraphs field
Then we can not add more paragraphs entities to an already translated node

Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Issue summary: View changes
sgurlt’s picture

Thanks 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.

Rajab Natshah’s picture

#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.

miro_dietiker’s picture

This 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...

miro_dietiker’s picture

I 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?

Rajab Natshah’s picture

Noted 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.

Rajab Natshah’s picture

Rajab Natshah’s picture

Status: Active » Needs review
miro_dietiker’s picture

Config needs a schema or things break hard. And we need a test scenario with this setting enabled.

Rajab Natshah’s picture

Status: Needs review » Needs work
Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

I have updated the patch to work Paragraphs 8.1.3

Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Status: Needs work » Needs review
Rajab Natshah’s picture

Issue summary: View changes
miro_dietiker’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

This 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.

Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Issue summary: View changes
robpowell’s picture

@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?

miro_dietiker’s picture

@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.

Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

@miro_dietiker Noted
Thank you for your review.

I have updated the Issue summary after your last comment yesterday.

Remaining tasks

  • Needs some extra test.
  • Also, need a combined test the content moderation fix.

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.

Given that we do have a content type "Landing Page" with paragraphs filed and number of paragraph types
When we create an English node (Default language) with number of paragraphs entities
Then the English node page will show the list of paragraphs in the Default language
When we translate the node into other languages
Then we will not be able to add/clone/delete On the first translation action
When we edit an already translated node which uses paragraphs field
Then we can add more paragraphs entities to an already translated node

miro_dietiker’s picture

If we allow structural changes later when editing a translation, why would you want to disallow this when adding a translation?

Rajab Natshah’s picture

Why would you want to disallow this when adding a translation?

I'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:

  • allow add paragraphs while translating
  • allow delete while translating
  • allow clone while translating
  • allow add paragraphs after translating
  • allow delete paragraphs after translating
  • allow clone paragraphs after translating

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

  • allow_reference_changes = true
  • allow_reference_changes = false

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.

caspervoogt’s picture

I 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.

vuil’s picture

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.

vuil’s picture

Issue summary: View changes
miro_dietiker’s picture

This feature is definitively incompatible with multilingual content moderation in our current implementation.

Berdir’s picture

What 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".

vuil’s picture

Assigned: Unassigned » vuil
Status: Needs work » Fixed
vuil’s picture

Status: Fixed » Closed (fixed)
GiorgosK’s picture

Assigned: vuil » Unassigned
GiorgosK’s picture

So 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