Integration with paragraphs asymmetric translation

We've used patch #33 to fix asymmetric translations, works perfectly!

I am using D10, Paragraphs 1.16, TMGMT, and cannot get the accepted job translations for paragraph fields into the node translation when it gets created. Or even on updates.

I've enabled translation on the node's "field_paragraphs" field, AND all the fields for my paragraph types.

I'm using non-patched paragraphs_asymmetric_translation_widgets module, and this patch.

I've also tried patch 122 and 128 on the original Paragraphs Experimental issue for asymmetry, same results.

Is there another step I could be missing? Does this not work with D10? All of the patches applied cleanly.

The patch from #33 ✨ Integration with paragraphs asymmetric translation RTBC almost did it for me.
But if the target translation had less paragraphs than the source, the extra paragraphs wasn't added.

I've moved around on some parentheses, so the condition is (OR):

• $referenced_entity->id() == $field_item[$property]['#id'] Same entity
• ($item_delta === $delta && !$is_target_type_translatable) Same delta, and not translatable
• $is_asymmetric_translation_mode Is asymmetric paragraph

The last submitted patch, 36: 3134922-36.patch, failed testing. View results →

This is the correct patch.

After I've been working more with the tmgmt module, I realized my previous assumption about the conditions in findReferenceEntity() was wrong (and introduced an error where the first paragraph was chosen for cloning each time).
Sorry if this has caused any confusion!

Anyway, I think the problem (in my use case) is the $entity passed to the doSaveTranslations() function, is not using the jobs source language.

I've supplied a patch that sets the entity language in the saveTranslation() function.

If a corresponding paragraph does not exist in the targeted translation, the strings submitted in the tmgmt form will be lost upon completion.

I modified the patch #39 by @birk to create a paragraph.

I hope what I made here makes sense.

Hi guys,

The source language issue has been raised separately in this issue: https://www.drupal.org/project/tmgmt/issues/3242174 🐛 ContentEntitySource is using entity's source language instead of job's source language when saving Needs review
I think let's help review and test the patch there so we don't feature creep this issue

Regards

Peter

Patch #39 works for me, but not patch #40

I'm experiencing issues with this, we've been using patch #33 but when translating a node (page) that has revision referenced field to asymmetric paragraph fields, the paragraphs aren't saved properly.

At first it seems to all be working, but when using TMGMT to translate content (say from EN to FR) then we manually create a new translation (example: DE) and source it from FR the paragraph values aren't loaded properly into the fields. It gets them from en instead of FR. (The non-paragraph fields work fine)

I tracked this down in the database to see how things are saved differently when we save a translation manually vs when we use TMGMT to save it:

When creating translations manually: (where 387190 is the revision id of the paragraph in question) BELIEVE THIS IS CORRECT

1) paragraphs_item_revision and paragraph_item tables have fr code as opposed to en

mysql> select * from paragraphs_item_revision where revision_id = 387190;
+--------+-------------+----------+------------------+
| id | revision_id | langcode | revision_default |
+--------+-------------+----------+------------------+
| 119145 | 387190 | fr | 1 |
+--------+-------------+----------+------------------+
1 row in set (0.00 sec)

When creating translations with TMGMT: (where 387199 is the revision id of the paragraph that was copied for the new translation) BELIEVE THIS IS WRONG

1) paragraphs_item_revision and paragraph_item tables have en code instead of fr

mysql> select * from paragraphs_item_revision where revision_id = 387199;
+--------+-------------+----------+------------------+
| id | revision_id | langcode | revision_default |
+--------+-------------+----------+------------------+
| 119154 | 387199 | en | 1 |
+--------+-------------+----------+------------------+
1 row in set (0.00 sec)

2) The paragraphs_item_field_data and paragraphs_revision_item_field_data tables have 2 rows instead of 1. They have a default en row and an fr row sourced from en.

mysql> select * from paragraphs_item_revision_field_data where revision_id = 387199;
+--------+-------------+----------+--------+------------+-------------------+------------------+-------------------------------+----------------------------+------------------------------+-----------------------------+--------------+-----------+-------------+---------------------+
| id | revision_id | langcode | status | created | behavior_settings | default_langcode | revision_translation_affected | content_translation_source | content_translation_outdated | content_translation_changed | revision_uid | parent_id | parent_type | parent_field_name |
+--------+-------------+----------+--------+------------+-------------------+------------------+-------------------------------+----------------------------+------------------------------+-----------------------------+--------------+-----------+-------------+---------------------+
| 119154 | 387199 | en | 1 | 1696616632 | a:0:{} | 1 | 1 | und | 0 | 1700510495 | NULL | 3611 | node | field_page_sections |
| 119154 | 387199 | fr | 1 | 1696616632 | a:0:{} | 0 | 1 | en | 0 | 1700510495 | NULL | 3611 | node | field_page_sections |
+--------+-------------+----------+--------+------------+-------------------+------------------+-------------------------------+----------------------------+------------------------------+-----------------------------+--------------+-----------+-------------+---------------------+
2 rows in set (0.00 sec)

Does anyone have any insight on what's going on? Is this a bug with the patch, or is there something else going on?

To recap the original issue, the other contrib - Paragraphs Asymmetric Translation Widgets creates new, independent paragraphs per node translation. However, TMGMT doesn't follow the same flat structure, it creates a translation for a paragraph instead of cloning a completely new one. We were using patch #24 back in D9 and it worked fine. Upon upgrading to D10, we switched to a newer patch #33 and the original issue reoccurs.

I refactored the logic in #24 and added that to patch #33. When the asymmetric mode is on, TMGMT should treat the entity field as 'non-translatable' so it will clone the source entity instead of translating it.