New Plugin: Visibility per language

Looked at this, this morning. Not sure how complex this can get but here are some ideas. *Not tested*

1. In the global configuration choose what languages should be allowed. Multi select widget.

2. Expose the allowed languages in behavior form so user can select on what languages this paragraph should be visible on. Multi select or maybe check boxes?

3. In view restrict access to the paragraph with #access when the current language doesn't match the user selected ones.

It would be great if you could post the wip patch here given that the specifics are still a bit foggy :)

@dencev
1) Drupal maintains a site language list as configuration. All languages defined there will be relevant. We don't need additional configuration.

2) Defining this logic is the challenging part...
The default is to show all languages in Drupal. It would be better to select the ones that hide it. But negative checkboxes are a UX antipattern.
Compared the problem with the core proposal for block visibility: #2284687: Redesign UI for better management of block visibility

We think we should output
- A fieldset "Visibility per language" from the plugin
- A checkbox with 3 values: - Always - / Hide on / Show on
- A Select2 box that allows a user to easily pick some of the languages defined. This control is hidden if the checkbox before is on "- Always -"
The Select2 library is not yet used in core. We could also start with checkboxes only.

Languages
[ ] DE
[ ] FR
[ ] EN
Select languages to limit visibility. Visible for all languages if none are selected.

Not very fancy, but that's IMHO the standard pattern, and you can either implement that as a plugin or simply as a normal entity reference field to languages. If plugin, you could also include a switch to "Check to exclude" vs "Check to show", that's also sometimes helpful if only a few languages should be shown.

And then a bit of hook_entity_access().

It's likely you want to enable this behavior on many paragraph types if you need it... And the proposal above tried to find a way to not clutter the UI with checkboxes when you have many languages.

I have some working example but need to do some injections, coding standards, remove some hardcoded values...

Went with select2 route. Made a plugin. On one image is the selection of languages, I'm displaying all languages but have optgroup in select to first show languages that are enabled on the website followed by all the others that are defined in drupal. Not sure about that, I can remove it if its not useful.

Or do we want to skip select2 untill in core?

Here is first draft, needs test, will cover that if the approach looks ok.

IMHO we should convert the radio selection to a drop down. We want to see as few elements as possible in the UI.
Then the dashed notation is OK. (We typically don't use such a notation with radio boxes.)

Quick update: changes radios to select.

A UI update needs updated screenshots.

1. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,153 @@
   +    foreach ($this->languageManager->getStandardLanguageList() as $id => $name) {
   

   No. We don't need to do language discovery.

   We just need to list the INSTALLED languages. Content can only exist in these languages.

2. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,153 @@
   +    if ($visibility == 'always') {
   +      return $build;
   

   We can also exit if visibility isn't set at all.

3. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,153 @@
   +    if ($visibility == 'show') {
   ...
   +    if ($visibility == 'hide') {
   

   Comment what we do with this logic here.

4. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,153 @@
   +        foreach (Element::children($build) as $children) {
   +          $build[$children]['#access'] = FALSE;
   

   Why on child level and not on current build level?

Also, Zero documentation, Zero test coverage, Zero examples.

Tests are always critical for new functionality.
Definition of done is also to have demo extended with every plugin and a feasible example.

This plugin will need to provide a summary for the collapsed display.
Such as "Hide on German" or "Show on French".

I have some usability remarks about this solution:

If I understand correctly, this will force us to create all paragraphs inside a field. Then selecting which paragraph should be shown in which language.
If you do this, you will get a huge list of items per field on large websites (think about international websites that have a lot of languages), making the node edit form unusable. Even with 2 languages it would already become messy.

A node that is created in a certain language should not contain content from another language, unless the field is set as a non-translatable field, making the content be shared among the created language variants, and making it non-language dependent field.
Also think about the people that use this module as a page builder, the overview will completely be lost.

Further we also have to take into account that international websites a lot of times require a user to only be able to manage the content for a certain language.
By using this approach, this becomes impossible.

Further, this solution does not follow the default Drupal workflow for fields.
I suggest to reconsider the usage of the "Users may translate this field" checkbox on a field to localize a paragraph. This is the most logic solution in the eyes of Drupal best practice.

@hoebekewim Thank you for your feedback!

IMHO Your inputs are not related to the use case we are addressing with this plugin.

This plugin is not intended to create content that highly varies per language.
It primarily is to suppress a paragraph for a certain language, for use cases where things overlap to >90%.
In these cases, managing separate entities in separate UI contexts leads to disconnect and losing overview.

BTW if you really need content that varies highly (such as in commerce and regionalization) you can always create multiple nodes and limit their visibility by region. Then you have your wanted independent management.

I'm not rejecting the original requirement: The translatable ERR field still makes sense, but it's a huge leap in UX and user awareness. We currently still need to define the next leap in the experimental Widget UX. Once we are there, we can investigate more about multingual UX.

This plugin is just one option more to approach the problem.
We should possibly explain the use case in its description and even put a warning.

Let's get this done with the fixes in #13

The plugin should only be available if the system has more than one language enabled.
Let's create a follow-up to make the demo multilingual and add a nice use-case for this plugin.
But we will need a mulilingual test for the plugin as part of this issue.

Progress thus far.

Everything except for the demo works.

Will move all demo content into paragraphs_collection_demo_install and make use of isApplicable tomorrow.

Discussed with Miro.

1. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,150 @@
   +      '#description' => $this->t('Select a language.'),
   

   +++ b/js/language.js
   @@ -0,0 +1,18 @@
   +      $(".paragraphs-collection-language-visibility-languages").select2();
   

   initialise placeholder with jquery from #description and hide the original description. Example from select2:

   $('select').select2({
     placeholder: 'Select an option'
   });
   

2. +++ b/modules/paragraphs_collection_demo/paragraphs_collection_demo.install
   @@ -101,6 +101,13 @@ function paragraphs_collection_demo_install() {
   +  $language_paragraph = Paragraph::create([
   

   // @todo incomplete.
   Should be on a separate line.

3. +++ b/modules/paragraphs_collection_demo/paragraphs_collection_demo.install
   @@ -101,6 +101,13 @@ function paragraphs_collection_demo_install() {
   +  ]); // @TODO
   +  $grid_paragraph->setBehaviorSettings('language', []);  // @TODO
   

   Write @todo on separate line and describe what to do.

4. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,150 @@
   +      '#description' => $this->t('Choose to always show paragraph or to hide or show for specific languages.'),
   

   Drop this description.

5. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,150 @@
   +        foreach (Element::children($build) as $children) {
   ...
   +        }
   ...
   +        foreach (Element::children($build) as $children) {
   +          $build[$children]['#access'] = FALSE;
   +        }
   

   Set a variable and check that. Loop once to set the access.

Progress for today.

Some JS improvements.

Demo still needs more work.
I don't see how to activate a behavior plugin for a paragraphs type from paragraphs_collection_demo_install. I would like some feedback on that, @Berdir.

Do you mean how to enable a certain behavior on a specific paragraph?

$grid_paragraph->setBehaviorSettings('grid_layout', ['layout' => 'paragraphs_two_column']);

And save it.

That's configuring one that is enabled. Enabling one is on the paragraph type.

You can see how that's done in \Drupal\paragraphs\Form\ParagraphsTypeForm::save(). get the behavior plugin, set at least the enabled key in configuration, save the paragraph type. That's it.

Discussed JS implementation and it seems we were on the wrong path.
We can simply set a static placeholder text in the select2() initialisation...

We should not use JS to show / hide things. We have states for this.
Also, we should not set width in JS initialisation. We should always try to do this with CSS.

+++ b/modules/paragraphs_collection_demo/config/install/paragraphs.paragraphs_type.language.yml
@@ -0,0 +1,14 @@
+label: Language

An own type for "language" is a bad example. You better enable the Language plugin on the normal text paragraph type or some other demo type.

The demo works now.

Added a README.txt to document how to set up the needed Select2 library.

See my comment above.

Replaced the JavaScript with CSS, as requested.

Looks pretty and works fine on Firefox.

Doesn't work well on Chrome as the screenshot show.
Specifically, if the paragraph is saved with visibility at "- Always visible -", the edit form is loaded with the language selection hidden. This confuses the "smart" Select2 JS which sets the input element width by the style attribute to a default (style="width: 100px;").

This needs a re-roll first.

@Primsi: Here you go.

This needed another reroll. Also some additional feedback:

1. +++ b/README.txt
   @@ -0,0 +1,16 @@
   +   paragraphs_collection.libraries.yml file. (A leading "/" denotes the root of
   +   your Drupal installation folder.)
   +
   + * For the Slider plugin see https://www.drupal.org/node/2836082.
   

   We have an issue for the readme file, that will add the missing information. As for select2 I would prefer to have the instructions here (where to download it and where to put it).

2. +++ b/config/schema/paragraphs_collection.schema.yml
   @@ -21,3 +21,18 @@ paragraphs.behavior.settings.grid_layout:
   +      mapping:
   +        languages:
   +          type: sequence
   +          label: 'Languages'
   

   If those are language codes, core normally uses langcode (pl. langcodes).

3. +++ b/paragraphs_collection.libraries.yml
   @@ -7,3 +7,26 @@ grid_layout:
   +  js:
   +    /libraries/select2/dist/js/select2.full.min.js: {}
   +  css:
   +    component:
   +      /libraries/select2/dist/css/select2.min.css: {}
   

   Please add a follow up to provide a hook_library_info alter. See https://github.com/drupal-media/dropzonejs/blob/8.x-1.x/dropzonejs.modul...

4. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,149 @@
   + *   label = @Translation("Language"),
   

   Is "Language" descriptive enough? Maybe "Visibility per language"?

5. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,149 @@
   +        'always' => $this->t('- Always visible -'),
   +        'hide' => $this->t('Hide for'),
   +        'show' => $this->t('Show for'),
   

   We could make visibility values constants.

6. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,149 @@
   +        'id' => ['paragraphs-behavior-language-visibility-behavior-form-visibility-' . $paragraph->id()],
   ...
   +        'class' => ['paragraphs-behavior-language-visibility-behavior-form-languages'],
   ...
   +    $form['container']['#attributes']['class'] = 'paragraphs-behavior-language-visibility-behavior-form';
   

   Is there a reason for this ids and classes to be that long?

Obviously already needs another :S

I will take care of this.

I have time for this now again and @toncic doesn't. Taking over.

I would still like some feedback on the issue with Chrome and Select2.

Implemented the changes @Primsi asked for.

The Select2 select box width is still wrong. Upon further inspection, it doesn't in any browser. I don't think this is doable without JavaScript.

1. +++ b/src/Plugin/paragraphs/Behavior/ParagraphsLanguagePlugin.php
   @@ -0,0 +1,165 @@
   +  const ALWAYS_VISIBLE = 'always';
   ...
   +  const HIDE_FOR_SELECTED = 'hide';
   ...
   +  const SHOW_FOR_SELECTED = 'show';
   

   This indirection is not needed in a script language like PHP where you can use strings for values. For instance, it makes debugging harder: i always need to lookup the const to understand what string value in the stacktrace means what const.

2. +++ b/src/Tests/ParagraphsLanguagePluginTest.php
   @@ -0,0 +1,104 @@
   +      $paragraphs_field . '[0][behavior_plugins][language][container][visibility]' => 'hide',
   ...
   +      $paragraphs_field . '[0][behavior_plugins][language][container][visibility]' => 'show',
   

   See, we are simply using 'hide', 'show' string states.

Alright. Deleted the constants again.

Also, there is now a follow-up issue for the Select2 select box width problem: #2859251: Visibility per language Plugin: Select2 select box has a wrong width

Combining this plugin with other plugins like Accordeon or fixed grid results in a severe problem.
The position of each paragraph defines its role - this allows us to flatten the hierarchy and improve the UX. We thought it's a good idea.
Conditionally removing an item results in a shift, making the editing user unaware of the situation or even validation wrong (we wanted to validate child count in grid and accordeon).

There are two possibilities:
a) The plugin is considered incompatible with plugins that have fixed functional / layout expectation based on delta positions.
b) We will never do the delta based role approach (and change how grid, accordeon works!)
c) In situation where deltas impact the child role, only allow special rules with a fallback and offer a special container for this behavior. Example: A personalised special case always has the default fallback. A language specific paragraph in a grid needs to define an unspecific fallback...

Fun stuff to resolve. :-)

Based on miro_dietiker's coment in #53 it doesn't seem like it is a good idea to start using this patch in a real project right now.

Any idea about timeframe? Can we expect this approach to be pursued further?

@badrange Any funding of features such as this plugin would help to provide any timeframes.
We are only projecting timeframes if features are directly funded by projects.

Still prioritising up, because multilingual requirements are recently discussed more.

Re-roll.

What if we limit the applicability of this plugin to just a certain set of paragraph types in config for now?

Fixed the test. (There is a new permission required for editing behavior settings.)

So we should document in the layout plugin that it fits very well to row containers and individual content paragraph types. But if the parent is a container that applies to children semantic roles based on delta, it doesn't fit. We can't avoid this as we don't know which paragraph type acts like that.

Containers with a grid layout with fixed child modulo count do not fit. "Equal distributed" layouts would be ok.

We tried to avoid this pitfall for other applications such as an accordion where we added a accordion item with title and body child field instead of (odd/even) delta roles. It is a level of nesting more, but it is easier to apply constrains to limit what is allowed as title and UX is also better.

Lets get this in and then create a follow-up to avoid wrong selections by the user with better validation for the special cases.

Ok, let's update README

Don't forget to update the plugin description, so people are aware of the limitations in the plugin UI.

I have tested this with children of a Grid paragraphs type and I haven't seen any problems with any layout - whether fixed row length or "equal columns". There was just a hole in place of the invisible paragraph in each case.

Stopped loading the Select2 library, if it doesn't exist.
Disabled the behavior form for sites with only one language and added test coverage for that.
Updated README.md and the plugin's description.

There was just a hole in place of the invisible paragraph in each case.

And that's the problem. It's conceptually incompatible. It breaks layout expectations and it is misleading to the user.
Thus the recommendation is to NOT use per-language-visibility plugin in combination with a grid layout that has a fixed child count expectation. And that's what we need to document in the plugin description.

This needs the sort of fix that we did here: #2887748: Update tests with the recent changes

This plugin highly demands for the tristate issue. It leads to clutter of all Paragraphs and likely slow-down of the Paragraphs UI due to the large amount of UI elements it outputs (and then hides).

Fixed the tests analogously to #2887748: Update tests with the recent changes.

+++ b/src/Tests/ParagraphsLanguagePluginTest.php
@@ -62,7 +62,7 @@ class ParagraphsLanguagePluginTest extends ParagraphsExperimentalTestBase {
+    $this->drupalPostFormSave(NULL, $edit, t('Save and publish'), t('Save'), $edit + ['status[value]' => TRUE]);

Berdir pointed out there, that adding published status is not necessary, because it defaults to that.

Fixed the tests. And cleaned them up a little bit.

Before we test this again, let's wait until #2855309: Create ParagraphsTestBaseTrait. reverts the API changes it introduced by expanding the list of required parameters for some functions.

#2855309: Create ParagraphsTestBaseTrait. was merged.

It's passing the tests now.

Ok to get this in as is. But we need a new parent meta issue that cares about improving the multilingual UI.
That will be improved summary, published translation status fields, filtering elements on output, filtering on the translate tab and many more. We will need to create a special round of mock-ups also to design the resulting UX goals and sync with the old "translatable err field" wishes.

And to avoid the ui overload/clutter, we really need to have the tristate thing and should promote it.

Committed. Thanks. Leaving open until the follow ups from #18 #37 and #62 are created

Created the follow-ups:
#2893023: Make Paragraphs Collection Demo multilingual and add a usecase for the Visibility per language plugin
#2893027: Make the Visibility per language plugin use a hook_library_info_alter for the Select2 libraries
#2893019: Prevent ugly UI caused by the Visibility per language plugin by restricting its usage in containers

The new META issue is lacking any reference.