Translation of paragraph fields doesn't work since removing Inline Entity Form dependency in alpha3

Subscribing to this issue. We're also facing a problem with translations in alpha3. I will do some investigations now.

If i get it right, the multilingual support was skipped in #3068270: Remove Inline Entity Form module dependency. That means paragraph forms will always show up in the default language. I tried to bring that back on a basic level, heavily inspired by the paragraph widgets. It seems to work on my project but feedback is also appreciated.

Thanks @dermario! Really appreciate the work on this important issue. Will review and follow up.

Thanks for your feedback. We are also testing it and found an issue when adding new items.

Call to a member function setNeedsSave() on null

So i am working on it.

So we were facing the ajax error
Call to a member function setNeedsSave() on null in Drupal\entity_reference_layout\Plugin\Field\FieldWidget\EntityReferenceLayoutWidget->massageFormValues() (line 1034 of ... /var/www/project/site/web/modules/contrib/entity_reference_layout/src/Plugin/Field/FieldWidget/EntityReferenceLayoutWidget.php). when we try to insert a paragraph that contains an media library widget and
with the patch in #3 applied. This patch fixes the problem on our side.

We are also facing an issue when new translations are added:

• Create a new node in default language in german
• Add a section and a paragraph to it
• Save
• Translate the node and the paragraph field to french
• Save
• Result: Both the french and the german content are in french now

I will investigate and try to fix that.

I tried to fix my findings in #9 - it might be that it also fixes the problems in #8. I would love to hear some testing feedback again.

Thank you @seanm89 for your great help. This is really awesome. We're getting closer :) I also did some testing and could find no problem if the content "starts" in default language. I quickly checked your finding and can confirm that this problem exists. I don't think that this is the default behaviour and i will investigate again. I cannot work on that on thursday but i will work on it on friday/weekend.

Status update

I have updated the title so it is more specific to the regression that is being seen in the bug

I figured out that the paragraph that was saved in a form that isnt called from the default language was nevertheless saved with the default language. That leads to a translation error because the translation into the default language overwrites this false saved paragraph. When the paragraph was in the correct language after saving, the translation was successful. So I set the language for the created paragraph depending on the form language. @seanm89 maybe this helps :)

Hey seanm89, thank you for your testing and detailed description, that helps a lot.
Unfortunately, I can't reproduce your test case, but trying to reproduce your error brings me to another bug. Translating to the default language overwrites the existing paragraphs, translating to other languages does not, maybe this also causes your problems.
I will work on that and try to fix it.

It seems the translation logic was taken from the paragraphs module, but in paragraphs module you can only add paragraphs in the original language and not in the translation, and that is by design.
Related issues:
#2702947: Button "Add paragraph" removed if you create a translation node
#2669732: Buttons to remove and add paragraphs do not appear when changing the language of the host entity

Here is a patch that follows the same logic.

Reroll last patch.

Fixed last patch :).

Reroll last patch.

Hi!
@Silent-Murmur, @seanm89: Can you review the above patch?

Are we all sure we want to go the same road as Paragraphs? Not every site needs 1 on 1 translations and having the option to pick between sync and async translations would be nice.

I know paragraphs by design are not translatable, but I like many other still think that's a design flaw. Hence the discussions and various project trying to remove the burden of having 1 on 1 translations in paragraphs.

We use this module to allow our customers to freely design landing pages but a lot of times the content for other languages/countries is different but they still need to node to be linked together as a translation. So I believe that having the option to pick between sync or async translations is a must have for this module :)

I think the problem is that its difficult to do, which is why even though they are working on this for quite a while its still not in paragraphs.

If we block this issue cause of that we risk that this never gets in and so we have to keep patching the module or drop the idea of using it :(

But if you are already using this module in multi lingual sites then I guess you have a different patch for this already made?

This patch currently still works async, or at least in my current projects it does. That's why I was curious about the goals of this patch :-)

The reason it's not solved in paragraphs for a long time is a bit more complex. They have a legacy to deal with, over 100.000 installation use it and they simply can't break those sites ;) And with paragraphs you kinda needed to make nested paragraphs for what this module can do out of the box :)

Plus this module's installation base is rather small and the moving parts of this code are still in work in progress mode. Don't get me wrong, I'm not saying we should block this issue. Far from that! I see it more as a opportunity in trying to do it 'right' from the gate. :-)

I strongly believe that this module is the perfect modern alternative for the paragraphs widget, and that doing translations async is actually easier then doing it sync.

I walked that road a few years ago for the Inline Entity Reference with paragraphs combination. My solution back then was the extended paragraph entity and that kind of worked.

The widget in that module is async, the paragraph is marked as a translatable entity on a field level. and since i felt it was a bit to hacky I never released that module. Just moved that code to Github for this comment ;)

In the current state of this module all the paragraphs on the source node are deep copied to the translation target, so the link between the source and target is a one way trip and all the new translated paragraphs become a new entity instance of that paragraph with a language property. This module stores the target ID of that paragraph in the field table of the node they are attached to together with the language for that relation.

Making this relation fully synchronic is where it becomes complexer and more of a module/widget solely made for paragraphs. Nothing wrong with that, but I feel the code for that should be moved to the widget class or submodule and not hardcoded in this module for the paragraphs use case only.

Synced translation would imply for the dragula based widget we should completely disable the draging and moving on translated nodes, which is the thing that makes this module so awesome ;-) Instead of storing the language on the field, the language also needs to be stored on the target entity and not as a property of the source.

But if the desire still is that this module should be able to work with other custom entity types, then there is no way around either making it more flexible or rewrite the storage part of the widget. And then there is the question, will the only target still be just entities that are revision aware, or should 'simple' content entities also become a option. And in that case the current field storage system feels more suited as it could do both and let the widget/formatter combination determine the translatable part instead of baking it hardcoded into the module :)

(hopefully my rambling makes a bit sense)

If by this patch you mean the patch posted before yorks patch so #16, then it has issues, and what the last patch do I think is to remove the add option from the cases where it does not work.
So if #16 is good then #23 is also good but without the issues.

So you would prefer an entirely different approach if i understand correctly.

Can you contribute a patch which would work like you expect? And then we can help finalizing it.

I did test with #23, and either the cases where it should work aren't clear to me, or it doesn't work like expected ;)

Working on a patch, but it's going to take me some time as my open-source hours are limited.

@Rene Bakx:
Hi!
Can you describe how you have tested patch #23?
According to what we have found, if the ERL field is translatable, then the code in the patch wont apply as then it wont be translating the paragraphs themselves, but that is by design as then the translations are independent.

i "confirm" the bug and also #23 ...
but it's working only if i "Content language detection" on "Languages > Detection and selection" (admin/config/regional/language/detection)
even it's a replica of the "default" "Interface text language detection"

if i'll have more insights i'll try to share

I jumped on this with both of my feet. ERL needs proper multilingual support, and we will fix this properly.
Actually both the #11 and the #23 patches seems to behave properly from my first test (an English page with Italian and Spanish translations), bringing appropriate translation logic into ERL paragraphs.

I will go more through both code, to inspect what kind of regressions and downsides they have. I couldn't reproduce those described in #32 comment regarding the #23 patch, but I will test further.

I still have to realise how the #11 and the #23 patch differ in their code/approach (as they seem to behave the same).

Will update soon on this ...

I further tested the #11 and the #23 patches and it seems that they both works well, when starting the creation of the Layout Section from the Default Language, and then Translate on the other languages ... but I verified that also the #23 is affected by the same following issue highlighted by @seanm89 (in #12) on the #11 patch:

there is a strange case where if I create a new section with new data in not the default language,
as an example i have english (default) german and italian languages, if i create a new section and add a text item, and save it first in italian.
then that new section is replicated on english and german pages.
if i then edit the other non default language german and translate the text and save it thats fine and stays separate from the italian and english versions.

at this point italian and english have same text and german has different.
now if i edit the default language(english) and change the text and save the node, both the italian and english version change to match the english version, german still remains different.

From a better insight I realised that the above mentioned shouldn't not be considered bugs, as we should match the behaviour of the native Paragraphs widgets in the multilingual (content translation) context: Paragraphs cannot (and shouldn't) be added and removed in an translation edit context (different from the Entity host default language).

If we look both the Paragraphs widgets for the Entity Reference with Revisions field ( "entity_reference_paragraphs" & "paragraphs") it is to verify that it not allowed to create new Paragraphs (and remove the existing) in a translation edit context. It is only possible to Add new and to move their each other position.

So we should replicate the same logic for this ERL Widget, so that:
In a Content Translation edit context (different from the Default Entity Language) we should:

1. Impede the Creation on New Layouts and Paragraphs Items (inside them) ...;
2. Impede the Addition and Removal of new Layouts and Paragraphs Items ...;
3. allow Content Translation/Edit both for Layout ad Paragraphs, that will stay language/translation specific;
4. allow change of Layout Regions setup (1 column, 2 columns, etc), with the following 2 options:
   1. settings will be shared for all languages: all languages will have the same Layout Regions setup (easier);
   2. settings will be shared language specific: different language variant might have different Layout Regions setup (more flexible but potentially confusing and more complicate to achieve);
5. allow Drag & Drop of Paragraphs inside Layouts Regions, with the following 2 options:
   1. settings will be shared for all languages: all languages will have the same distributions of Paragraphs in Layouts Regions (easier);
   2. settings will be shared language specific: different language variant might have different distributions of Paragraphs in Layouts Regions (more flexible but potentially confusing and more complicate to achieve);

From a better and deeper testing I got the following substantial differences from the #23 and the 11# patch.

The #23 patch is already (almost) able to achieve all the above requirements, missing just the following: 1, 4.2 & 5.2 ...

The #11 instead is no able to achieve both 1 and 2 ... so indeed is not matching the Paragraphs editing behaviours for Content Translation (no new items in the Content Translation context).

I am going on with this review and will update on my further findings ...

The attached patch refactors the #23 applying better php/Drupal standards ... and also fixes $pluginFormFactory un-definition.
There are some Exceptions handling that should be added in the code.
The next patch will cover unhandled Exceptions that should be added in the code, bug fixes and better implementation of translations logics in the widget.

The attached patch is a further step forward (of the previous #38) because it implements the correct handling (& catch) of \Exceptions ...
After some brief testing it seems to work well, implementing the following requirements, based on the #37 list: 2 - 3 - 4.1 & 5.1

So it seems that it is still missing the requirement 1 (Impede the Creation on New Layouts and Paragraphs Items inside them ...) and I will go on to implement/fix it ...

The patches #39, #23 do not apply to the latest dev version.

thanks @a.milkovsky ... going to tune and reroll next patch asap.

Re-rolled 39.

The patch.

Sorry for the weird interdiff file. Ofcourse I can not create an interdiff for the re-rolled patch.
The code in interdiff if the rejected part.

Thanks @a.milkovsky ... but please let's not mess up here. We are working (full time) with the main maintainer to fix this, so no need to overlap in coding. Would be better just testing and reviewing these improvements.
In this meanwhile (few minutes ago) the dev branch went far ahead, with a huge commit from the General UI and Javascript Improvements issue.
So this issue patch will need to be rerolled/refactored to it (I will do that ...).

In this meanwhile you could test this last version patch from the #39, that applies to this commit: d60d9fd

It seems to work fine for me, but I will still test it better.

I have tested the patch. The multilingual functionality works in general. I can translate my node. But there are 2 issues.

My setup:

1. I have a "Text" paragraph, with a field "Text" which is translatable.
2. I have added the "Section" paragraph well as described in the module page.
3. I have a paragraph "Layout". I have added the entity_reference_layout field to this "Layout" paragraph instead of a content type. I do not need to replace entire paragraphs widget with layout builder. I referenced the "Text" paragraph in this field and used "Section" paragraph type for layouting.
4. I made the "Layout" paragraph translatable (but not the entity_reference_layout field).
5. I have a content type "Page" with a entity_reference_revision field. It references both "Layout" and "Text" paragraphs

Test scenario 1. Can not edit node:

1. Create a page in German (the website default language)
2. Add a layout paragraph, chose Three column layout.
3. Add a Text paragraph into the layout paragraph into the first column.
4. Save the node.
5. Edit the node.
6. Add a Text paragraph to the 2nd column.
7. See an error, that the form can not be saved, because of the "Layout" field.

Expected: node should be editable.

I have also tried to make "Section" paragraph translatable, but it did not help. When I deactivate translatoin on all the paragraphs, I can edit the form without any problem.

Test scenario 2. Translatable fIeld has "(all languages)" in the field label:

1. Create a page in German (the website default language)
2. Add a layout paragraph, chose Three column layout.
3. Add a Text paragraph into the layout paragraph into the first column.
4. Save the node.
5. Add an English translation
6. Edit the text paragraph in the layout paragraph
7. See that the text field says (all languages).

Expected: The text field should not have (all languages) in the label.

Ah! thanks @a.milkovsky for your review feedback. I will try to reproduce your use cases and bugs ... and figure out how to fix them. ;-)
Of course every suggestion, improvements and meanwhile findings are welcome ...

Note: In my testing I just compare a normal paragraph field behaviour, to the ERL field one.
We assume (Justin, the creator of this module agrees) we want to correctly replicate the Paragraphs multi language / translations behaviour ... (without reinventing the wheel and NOT going further/ahead of it at this stage).

@a.milkovsky I tested further ... replicating your use cases, and sincerely I can say that the widget is working (quite) great, instead.
Indeed, I couldn't reproduce both the bugs in your Test Scenario 1 and 2.

I didn't have any error in your Test Scenario 1: may you test it better, tell us more about it, may be even with a screenshot ... and a clear (and easy) way to reproduce?.

To make the Test Scenario 2 work properly I had to make sure to properly setup translation as ruled in the Nested Paragraphs scenario (@see here: https://app.getpocket.com/read/2640343685), and it worked properly also in Nested Paragraphs scenario (great!, it seems ...).
Make sure all the Paragraphs are translatable but not are their Entity reference with revisions fields, and start over building your nesting structure once corrected them (the fixes/updates won't work on existing structures, and should be set up correctly before building your content).

The only evident bug that is discovered is the following:
correctly I am not able to add both a Section/Layout and an Item/Paragraph in a translation context (edit in a language different from the original), but once I edit both a Section/Layout and an Item/Paragraph then the Add buttons and functionalities become active both on Section and Item level. And this shouldn't happen (and will be fixed).

@itamair, thank you for sharing your results!

https://app.getpocket.com/read/2640343685

This link does not work.

I have used this link while doing my setup: https://www.drupal.org/docs/8/modules/paragraphs/multilingual-paragraphs....

Make sure all the Paragraphs are translatable but not are their Entity reference with revisions fields

Did you make your "Section" paragraph translatable as well?

Unfortunately I have uninstalled the entity_reference_layout module already.
After some tries in the last days and discussion with colleagues we switched to a pure paragraphs solution.
I have created a few paragraphs "3-Column", "2-Column", what is enough for our current project. I might come back to this module in case we need some complex content-structures.

Thank you and best regards,
Alex

Ah sorry @a.milkovsky, here is the correct link:

Correct setup of Nested Paragraphs Translations:
https://www.amazeelabs.com/en/journal/nested-paragraphs-translation

All the paragraph types entities should be made translatable, in at least one of their fields (published, or author, etc) but their entity_reference_revisions || entity_reference_layout fields.

Ok, and here we go. With the last adjustments this new attached patch (that still applies over this commit: d60d9fd)
should work fine and respect the actual target requirements for Entity Reference with Layout components Translatability.

It means comply/replicate Multilingual Paragraphs configuration setup and Correct setup of Nested Paragraphs Translations

thus in a Content Translation edit context (different from the Original Entity Language) respect the following requirements/functionalities:

1. Impede the Creation on New Layouts and Paragraphs Items (inside them) ...;
2. Impede the Addition and Removal of new Layouts and Paragraphs Items ...;
3. Allow Content Translation/Edit both for Layout ad Paragraphs, that will stay language/translation specific;
4. Allow change of Layout Regions setup (1 column, 2 columns, etc):
   1. settings will be shared for all languages: all languages will have the same Layout Regions setup (easier);
5. allow Drag & Drop of Paragraphs inside Layouts Regions:
   1. settings will be shared for all languages: all languages will have the same distributions of Paragraphs in Layouts Regions (easier);

I will re-roll this patch to apply on the actual dev branch (asap) and test it some more, for RTBC ...

Ok, and here we go, again ... and finally.
The attached patch applies cleanly on the present 8.x-1.x-dev branch,
still respecting the requirements listed in the #52 comment,
and moreover implements also the following functionalities:

• a styled warning message inn the ERL widget build, if this is in a Translation Context, to specify that a version not in the original language is being edited and no new Layout Sections and Items can be added (@see attached image erl-translatability-3093875-55_1.png);
• implements entity_reference_layout_form_field_config_edit_form_alter to Indicate unsupported multilingual ERL field configuration, as in paragraphs module (@see attached image erl-translatability-3093875-55_2.png);

Besides the above, the patch also fixes some/many pph/drupal coding standards, and also css styles rules.

I have tested this extensively, and it is working great (it seems to me), also in a nested Paragraphs scenario.
Ready for your review, and your feedbacks, so as heading to RTBC ...

Slight (coding standards) updates to the previous patch, all remains what said in #55

Thanks for the work on this! Really excited to see translations working with ERL. Pushed and marked as fixed.