Add layout builder (inline) block support

I can confirm that the nested inline blocks are being sent and received but once the entities are saved the nested inline block is not saved. If if they are saved the wrong revision or target_id is used in the translation.

Here's an updated patch addressing the nested inline blocks issue.

Can confirm that the patch on #25 applies cleanly and that the nested (child) inline blocks are translated.

Add a check if the field exists.

there is another issue in the patch, a huge number is created from each translated block... after translating a page that has a layout containing 4 blocks only we found that the blocks has been created multiple times, same content and everything but duplicated many times.. we found this after we noticed the site became too slow..

This patch addresses the following issues within the system, specifically tested on 'layout_builder_at':

1. Remove Duplicated Blocks:
Duplicated blocks of code or content are now systematically removed, enhancing system efficiency and minimizing redundancy.

2. Separate Inline Block Translations with Unique IDs:
Each inline block's translation is assigned a unique ID, intricately connected with the original ID within the configuration. This prevents inline blocks from disappearing in the source language when updating other translations. Notably, the configuration of the component's fixability becomes crucial, as it ensures a sensible handling of inline block translations.

3. Restrict Display of Inline Blocks on Source Page:
Given that inline blocks are inherently connected to entities and cannot be individually translated, there is no need to display them on the source page. This restriction streamlines the visual presentation of the source page.

4. Enhance Functionality of Inline-Block Translations and Nested Inline Blocks:
Bugs have been addressed, and new features have been added to optimize the translation process:

- Blocks not present in the source language can now be retained without disappearing during translation requests.
- Adding a new block in the source language and subsequently requesting translation via TMGMT will only include the newly added block and they will appear on the bottom of the page to void conflicting with other blocks.
- For retranslation needs, simply deleting a block from the translated entity and requesting translation will seamlessly add it again.

It's important to note that this patch has undergone testing exclusively on 'layout_builder_at'. If you have further questions or need additional details on the implementation, feel free to inquire.

continuation of patches #30-#32 fixes.
This patch addresses the error with Drupal\Core\Entity\EntityStorageException: Invalid translation language (es) specified, caused by non-Block content type entities accessing the code.

Guys,

Please do not refactor/fix coding standards of non-related code to this issue, you are causing at least a merge conflict and a lot of mess, this is not a scope of the issue, it's a purpose of a separate issue in the project

I've reverted the out of scope changes in the MR. Unfortunately, none of the patch changes since about comment #23 are in the MR. If there are features in those patches that need to make there way into the MR, please post to it instead of a new patch.

I think (hope) the JS test failure is a random failure. But everything else is green again.

Dug into the last failing test (JavaScript). After running it several times on local, I've come to the conclusion it is a random failure. After all that, it also now runs green on the testbot. The MR is now ready for a round of reviews.

One note about the code in the MR. "Add to cart" does not select layout blocks. Only "Request translation" selects the layout blocks.

One note about the code in the MR. "Add to cart" does not select layout blocks. Only "Request translation" selects the layout blocks.

Indeed, that was the case.

I have added support for that.
Sadly I needed to do that with a work-around.
For some reason the form state value related to layout builder toggle is not available on the cart submit callback.
So, I have added a form state arbitrary value based on the actual value of the toggle, at the validation stage, which is the last I moment I see it there.

I just wanted to comment that this only supports content blocks, it would be nice if it supported config blocks too.

I'm working on it locally and will submit it back, but I'm leaning heavily on how lingotek did it here: #3180664: Layout builder symmetrical translations support →

Even cutting out the nice symmetrical vs asymmetrical handling locally it seems to pull in the config blocks.
Setting this to needs work, but if that is out of scope for this issue let me know.

Having worked with this for a bit, this isn't the right issue for what I mentioned in 42.

I'm doing a review now.