When cloning the blocks it does not assign the correct language to the block.

2 remarks on this approach:

Templates that are stored in the library should have the language from the host entity from which they were cloned.
With the changes you are proposing this could differ. Assume you are editing a page in a certain language (Chinese), while keeping the admin interface in another language (English). The current language would be English, but the template you are storing in the library should remain in the Chinese language, because it was cloned from a Chinese language page.

Templates cloned into a page from the library should take on the language of the entity on which they are cloned.
This is basically the same as the above, but in reverse.
It also applies when you are simply translating your website and using templates created in another language.

I suggest passing the host entity to the clone functions and getting the language from there.
But I don't see anyway of doing that with the current code as it does not contain the host entity anywhere...

Thomas Cys → made their first commit to this issue’s fork.

"But I don't see anyway of doing that with the current code as it does not contain the host entity anywhere..."

I was looking at the code for this a bit. From the submitForm methods you could pass the section_storage context 'entity' which is assigned to $layout_entity (this is the node being edited) and pass that to the deepClone methods. There you can then use the $layout_entity->getLanguage()->getId() to set the langcode.

Also then set the langcode on the section being create or updated before the $section->save in the submitForm code after the cloning has been done.
$section->set('langcode', $layout_entity->language()->getId());

I will try to cook up some patch.

I agree that it makes sense to save the templates to the library in their original language, but it also makes sense for the sections inserted into a node to have the same language as the rest of their host page.

Are there any circumstances where someone might NOT want an inserted block to have the same language?

The current MR would simply set the templates to use the site default language and when they were inserted into a node, continue to use the default site language on those blocks.

If we want to only change the language to match when the blocks in a template are used in a new node, then the key place we need the host entity context is when cloneAndReplaceSectionComponents is called from ImportSectionFromLibraryController. We wouldn't need the context when adding the template to the library. I think we'd have to adjust the cloneAndReplaceSectionComponents function to take an optional language argument and then use something like:

     try {
        $layout_entity = $this->sectionStorage->getContextValue('entity');
        if ($layout_entity instanceof ContentEntityInterface) {
          $language = $layout_entity->language()->getId();
        }
      }
      catch (ContextException $e) {
        // Not inserting into an entity
      }
     if (!isset($language)) {
       $language = \Drupal::languageManager()->getCurrentLanguage()->getId();
     }

     $deep_cloned_section = $this->cloneAndReplaceSectionComponents($cloned_section, $language);

I think we need a clearer idea of the desired behavior from a few users who are actively using the multi-lingual capabilities of Drupal.

Everyone working with me (4 people) agree on my approach described in #3.

1/ Export the templates in the language of the host entity they were created from
2/ Give templates the language of the host entity on which they are imported (this one prevents serious technical issues also)

Alrighty - that makes sense. In that case, the current MR doesn't accomplish that, so if someone who is using language wants to tackle....?