Experimental widget displays the original language on translation

Hi all,

I'm working on a project with Drupal 9.4 where I'm using layout paragraphs 2.0.1 with the experimental widget. As stated in this issue, whenever I translate an entity, the process is correct. However, editing the paragraphs on the translated entity also changes the values in the untranslated entity.

Not sure if this is because the rendered form is not the correct one, or because the paragraphs aren't being translated so it just renders always the untranslated ones.

Are there any temporary solutions until this patch is applied to the main version? I've tried recreating the code on the pull request but I failed in doing so.

Any help would be very much appreciated as I'm really stuck with this.

Kind regards,
Ismael.

@j-lee: hi, I've tried to manually apply your patch to the current -dev version (without patch from #3259729).

The concept looks fine: now the experimental widget use the correct language. But the save/close/cancel buttons doesn't work anymore.

Did the buttons work on your branch?

Thank you very much!

patch no longer applies

Updated patch attached.

The patch from #14 works as advertised, but not 100% correct, at least for my scenario. Say I have 2 languages en and de. I create content in en and add a translation for de. Editing the translation works as expected, but the preview shows then the english page. Reloading the page shows then the updated content in the correct language.

1. +++ b/src/Form/LayoutParagraphsBuilderForm.php
   @@ -93,7 +93,8 @@ class LayoutParagraphsBuilderForm extends FormBase {
   -    string $view_mode = NULL) {
   +    string $view_mode = NULL
   +  ) {
   

   Unrelated change.

2. +++ b/src/Form/LayoutParagraphsBuilderForm.php
   @@ -225,8 +245,7 @@ class LayoutParagraphsBuilderForm extends FormBase {
   -    }
   -    else {
   +    } else {
   

   Unrelated, and incorrect change - elses should not be coddled.

Surprisingly, the MR's branch (which is currently hidden) *doesn't* have the problem described in #15, the incorrect return to the default language when working with a translation.

However, that currently conflicts with the 2.0.x branch and needs a rebase.

(BTW it gets confusing when an issue has BOTH a MR and patches!)

Trying to rebase the branch...

Does anyone know why the MR removes this code from LayoutParagraphsBuilderForm::submitForm():

    // The entity may have been altered by another process, and needs to be
    // loaded from storage to ensure edits to other fields are not overwritten.
    // @see https://www.drupal.org/project/layout_paragraphs/issues/3275179
    $entity_id = $this->layoutParagraphsLayout->getEntity()->id();
    $entity_type = $this->layoutParagraphsLayout->getEntity()->getEntityTypeId();
    $entity = $this->entityTypeManager->getStorage($entity_type)->load($entity_id);
    $field_name = $this->layoutParagraphsLayout->getFieldName();
    $entity->$field_name = $this->layoutParagraphsLayout->getParagraphsReferenceField();

Filed #3352152: Get the request time to set on the updated entity in LayoutParagraphsBuilderForm for the use of the time service which is in the MR here, and unrelated to this issue.

This code (and related changes) probably also needs moving to a separate issue:

+  /**
+   * Should new revisions created on default.
+   *
+   * @return bool
+   *   New revision on default.
+   */
+  protected function getNewRevisionDefault($entity) {
+    $new_revision_default = FALSE;
+    $bundle_entity = $this->getBundleEntity($entity);
+    if ($bundle_entity instanceof RevisionableEntityBundleInterface) {
+      // Always use the default revision setting.
+      $new_revision_default = $bundle_entity->shouldCreateNewRevision();
+    }
+    return $new_revision_default;
+  }

EDIT On second thoughts, I don't know -- nothing in the MR call this method!!! And I don't understand whether the intention is that a new revision is created for the parent entity or the paragraph!

Thanks for the feedback @J-Lee.

You're right, the MR is really out of date.

Also, it's trying to fix the problem by removing the use of the custom form element, which surely isn't right:

    $form['layout_paragraphs_builder_ui'] = [
      '#type' => 'layout_paragraphs_builder',
      '#layout_paragraphs_layout' => $this->layoutParagraphsLayout,
    ];

If the custom form element is showing the wrong language, it needs to be fixed, not bypassed!

Things in the patch don't look right either though:

      // Load the correct translation for the layout paragraphs layout field.
      $default_langcode_key = $entity->getEntityType()->getKey('default_langcode');
      $langcode_key = $entity->getEntityType()->getKey('langcode');
      $langcode = $entity->get($langcode_key)->value;
      if ($entity->hasField($default_langcode_key)) {
        $entity = $entity->getTranslation($langcode);

$entity is already in the correct language at this point, because it's loaded by the routing system which takes into account the current language.

          $entity->$field_name[$delta]->entity = $paragraph;

Setting the paragraph BACK into the entity looks really wrong!!!

I've tried your suggested fix for the patch:

+      $entity->$field_name->setLangcode($langcode);

It doesn't work - when I click the Save button, I see the original language for the paragraph and not the translation.

I'm not sure about doing that to the $field anyway -- it's an entity reference field, so it won't be set to translatable.

I think we need to add the $entity as a constructor parameter to LayoutParagraphsLayout:

$this->layoutParagraphsLayout = new LayoutParagraphsLayout($field, $layout_paragraphs_settings);

I don't think we can get the right language from what it currently receives.

We get $entity->activeLangcode set to the translation language, but $entity->FIELD->parent->entity->activeLangcode is set to the **default language**. So we can't get hold of the correct language to use.

I've got this working!

Thanks for your help @J-Lee!

Work is on a new branch '3305070-set-language-on-layout' with a new MR.

@joachim, @J-Lee thank you guys, you are life savers on that issue !

The patch works !

Hope the MR will be approved and released in the next module's version.

Edited :

Actually there is still an issue dealing with multi languages using the experimental widget :

1- use the widget to add a paragraph on the main site's language
2- save the page
3- got to another language version of the page
4- click the "Edit components" button
5- you will receive the following error:

"InvalidArgumentException: Invalid translation language (en) specified. in Drupal\Core\Entity\ContentEntityBase->getTranslation() (line 874 of /app/web/core/lib/Drupal/Core/Entity/ContentEntityBase.php)."

Thank you again @J-Lee.

Another issue remains however. When clicking the "Save button" at the bottom of the layout paragraph builder interface (to save paragraphs items order) the page is reloaded and paragraphs are displayed using the default language like described in the comment #15. Then if you click the "Close button", the paragraphs are back in the correct language. I don't know if it is linked with your proposed solution in the MR, but it would avoid confusion for editors and need to be fixed too.

@jleehr thanks so much for the suggested changes to MR122. I included them in a patch file and tested locally.

My experience was that the error that @grumpy74 described did not appear, so that's great.

However, in my testing the new paragraph that I added on the site's main language did not show up when I edited the page in an alternate language.

I'd be curious to hear whether others experience the same thing using patch 36.

@COBadger thank you for the provided patch. I tested it and it seems to fix the issue with the language code I was pointed out.

However. There is still another problem remaining.

Reproduce the steps described in my comment #33.

Then, when you have a node with paragraphs created and you have already the translated node created afterward, the paragraphs exist on the translated node too. But as soon as you re-edit the default language node paragraphs to add new one for example, here comes the issue.

Basicaly at that point the default language has a new paragraph added to the items list, but the translated node do not have that reference yet. So if you go to the translated node front page you see the newly added paragraph in the widget preview (which is correct), but as soon as you click "Edit components", the display switch to the edit display and the paragraph disappears (because actually the paragraph translation do not exists). I think when the widget switch to edit mode, the same kind of test on the paragraph translation existence must be done. Like if the paragraph do not exists for the translation language, in edit mode, we must create a new paragraph translation when clicking "edit" icon to be able to add the translation instance of the paragraph to the translated node.

On the other hand (and it is not part of that specific issue), the widget should not propose the controls "add", "duplicate" or "delete" on a non default language entity, as this is forbidden by design by the paragraphs principles (paragraphs are ISO between languages).

I hope my description is clear enough for the context overall understanding.

On my side for instance, I took the decision to write custom code to force node translation creation and paragraphs translation creation on node post save to avoid that issue (which is not ideal, but it fits my needs so far), but it should be handle by the widget IMHO.

Hope this will help resolving the issue. I'm sorry to not contribute actively on the code part of this, but I can help by testing patches.

I'm not managing to reproduce the error described in #33.

I tried both with a node that didn't have a translation, and one which did.

Please could we stick to the MR and not also make patches? It's going to get really confusing if we have both MRs and patches floating around.

I'm working on tests :)

Added test.

Changing status back to "Needs work".

In my test of the merge request I took the following steps:

1. Created a new paragraph in the original language of a node
2. Navigated to a translation of the node
3. Opened the layout editor
4. Observed that the new paragraph from Step 1 above did not render in the layout editor as expected

With the logic from my comment on the merge request when I performed the above steps I did see the new paragraph in the layout editor, and it saved as expected.

> 4. Observed that the new paragraph from Step 1 above did not render in the layout editor as expected

Do you mean that the new paragraph *should* appear there?

As the tests have passed I'm marking this RBTC.

Thanks for the fix.

However, people who've worked on the MR shouldn't set it to RTBC - that should be done by reviewers.

Thanks for all the work on this. Unfortunately, I think this needs a little more work. I don't think we want to add translation functionality directly into the LayoutParagraphsLayout class, as it assumes a little too much about possible use cases. Specifically, I'm concerned that this does not accommodate asymmetric paragraph translations.

So... I think we need to keep functionality specific to translations in the widget / formatter, and not in the underlying API classes. It might be worth abstracting the translation functionality into either a service or trait that both the widget and formatter can use, or refactoring the formatter so it just invokes the widget -- rather than directly using the layout paragraphs builder render element.

We're currently sticking with version 2.0.0-beta9 for this module due to its compatibility with multi-language websites. Newer versions of the module aren't suitable for such websites. Any help would be appreciated.

I'm using the module's version 2.0.4 with this MR's patch (https://git.drupalcode.org/project/layout_paragraphs/-/merge_requests/12...) for symmetric paragraph translation.

This module forces you to use go with asymmetric translation, which is not official supported (nor recommended) by the paragraphs module itself.

If you can explain the incompatibility issues you have, we can try to guide you?

We were able to update to 2.0.4 on several multi-language websites and use async translation successfully with the provided patch. Thank you!!

Trying to combine this MR with the one from #3269138: Support revisions and content moderation with the Layout Paragraphs Builder Field Formatter as both deal with the same part of the widget that needs some love. I noticed a discrepancy in how one method has a fail-safe for missing translations and the other does not. Will fix in the combined patch that I'm working on to see if it holds up.

Re-rolled patch for 2.2.x

I am facing the same issue and tested all the patches provided in this issue, but none of them resolved my problem.

Environment:

• Drupal core: 10.6.2
• layout_paragraphs: 2.1.1
• Languages: EN (default) and DE

Steps to reproduce:

• Create a content type with a Paragraph field (entity_reference_revisions), including nested paragraphs and media fields, make nested paragraph fields as translatable
• Create a node in EN.
• Add a DE translation and verify on the frontend — it works correctly.
• Go back to the EN version and edit some fields inside paragraphs and nested paragraphs.
• Save the EN node.
• Open the DE view page.

Actual result:

The DE translation content is overwritten with the updated EN paragraph values.

Expected result:

Saving or updating the default language (EN) should not override paragraph or nested paragraph content in other translations. Each translation should retain its own independent paragraph field values.

Edited:

Ignore it, it is working fine after some configuration changes.