Translation Problem with Paragraph 1.6 and Paragraphs asymmetric translation widgets 1.0-beta1

I had the same problem and the patch from #2 worked for me. Thank you very much!

Seems to me like you experienced an issue by switching from the patch to this module, but having created or updated content without having set up translation correctly for your paragraph field.

Can you please provide exact steps to reproduce this issue?

Once correctly setup this error should never appear. Content migration after switching settings is not supported and the patch you provided is basically a workaround for broken content...

@pbonnefoi Thanks for the extra info.

As I suspected this is an issue with paragraphs content that was created before implementing the widget from this module. In theory you should delete all your translations prior to installing this module and retranslate after setting it up. Not doing so will result in a lot of "stale" paragraphs in your database.
The use case for migrating paragraphs from one system to the other is not supported and would be a very big task indeed...

The patch from #2, will (I think) not actually fix the issue, but rather "mask" it by duplicating your old translation. So you are probably left with 2 paragraphs per translation by using this patch. One from before using this module, which will become a stale paragraph, no longer used anywhere. And 1 duplicated paragraph which you will be seeing and editing.
While this patch will actually resolve your issue it will also create a huge mess of stale paragraphs and field data in your database. But you would need to actually confirm that for me since I don't have any setup with this configuration to test on...

I've attached a patch, which I think will still solve your issue, but prevent this duplication mess. Can you test it and confirm it works? Could you also dive into the database and figure out if the previous patch left stale paragraphs? (and this patch doesn't?)

We're also seeing this exact issue when a translation is created before the widget is changed. The latest patch provides a good workaround. We're now trying to establish whether its possible to delete the translations and clean up the database that way, then recreate them. Or whether there will still be 'stale' rows in the db.

Confirming that #8 patch works / database looks fine. Re-rolled on 8.x-1.x / 1.0-beta-2. Perhaps we could still have another review?

I came here from a TMGMT setup, documenting for others that might have meet this, with the steps to reproduce.
- Given a node EN source, and DE translation done via TMGMT
Behaviour:
- The DE frontend is displaying the DE translation
- The DE edit form is displaying the EN source
- Cannot be reproduced while doing a manual translation
- Switching the form display to 'Paragraphs classic' displays the right translation on edit form
- Applying the patch from #8 / #10 solves the issue

Tagging for DrupalCamp Colorado's upcoming contrib day.

The patch #10 resolved the issue.

Setting back to "needs work".

The concept of async behaviour is that you have different paragraphs in different languages, NOT translations.
Simply loading the translations might look like a fix, but it is not.
You would need to duplicate the paragraph with the content from the translation.

Although I do still believe that this is way out-of-scope for the widget.
Switching from sync to async or the other way around requires content to be re-generated (if it exists) This could potentially be a very heavy workload and should not be handled in the widget, but at the time if making the switch.
Also note that switching from async to sync is technically impossible to handle correctly.
Switching from sync to async should be possible.

There has been this issue #2992777: Implement a migration path going on "forever".

Closing this as a duplicate of #2992777: there seems to be some good work going on there, will try and check that.