Missing active language when adding translation to media while editing through modal (AJAX)

After discussing with a colleague, we both came to the conclusion that the provided patch does not touch the appropriate place to fix this issue. With some more digging, I found out that it is possible to trigger a translation creation form in a modal with an addition to the MediaForm as follows:

 public function buildForm(array $form, FormStateInterface $form_state) {
    if ($this->getRequest()->query->get('media_library_edit') === 'ajax') {
      $form_state->set('langcode', $this->languageManager->getCurrentLanguage()->getId());
    }
    return parent::buildForm($form, $form_state);
  }

Unfortunately, there is no hook early enough to inject this behavior. Extending the MediaForm class is probably too intrusive. Also, there are more issues arising, i.e.:

• Modal title is not displayed correctly, when creating translation.
• Default values from default translation of media entity are not populated.

Hence, we may would need to stick to the suggested approach in the patch.

The MR 16 works only when the page is in the language is needed to translate, but it is possible to add a translation in another language.

Example: mysite.local/node/23/translation/add/en/fr. In this case, the edit URL will appear in the current language, instead of french it will appear the current language.

Please review MR 18 which takes in account target translatiion route parameter, which should work fine.

@omarlopesino I don't see how your patch addresses the original issue. If you found another problem, please do not extend the scope of this issue, but rather open a new one.

MR16 did not work for me cause it kept throwing Invalid translation language (und) specified.

I made a simpler patch, as actually when adding translation we normally don't need to save the return value of the addTranslation method, but we can simply save the entity.

And this works for me at least.

So this new patch is almost the same as MR16, but instead of making $media to be the return value of addTranslation, It receives the original media entity with the added translation, which works better for me.

So the change is at

$media_original->addTranslation($current_langcode, $media->toArray());
$media = $media_original;

I am surprised that makes a difference. You see this pattern $translation = $entity->addTranslation($langcode, $entity->toArray()); quite often, even in Drupal core. Can you describe the issue with the und langcode a little better?

The error message is similar to the related issue: 💬 How to translate an entity programmatically Closed: outdated

What I got is

Drupal\Core\Entity\EntityStorageException: Invalid translation language (und) specified. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 818 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

#0 core/modules/media/src/MediaStorage.php(29): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\media\Entity\Media))
#1 core/lib/Drupal/Core/Entity/EntityBase.php(354): Drupal\media\MediaStorage->save(Object(Drupal\media\Entity\Media))
#2 modules/contrib/media_library_edit/media_library_edit.module(204): Drupal\Core\Entity\EntityBase->save()

I got the same issue in a custom migration recently where I added translations to Media.

I had no time to dig very deep unfortunately. But when I search for addTranslation in core, I see examples for both usage.

But saving the media entity this way worked in my migration and also in this patch.

I have 3 translatable field, and 1 term reference which is not translatable on the media entity.
Maybe it has something to do with the not translatable field in that case.

simonbaese → changed the visibility of the branch 3404209-missing-active-language-2 to hidden.

Applied suggestions by @nagy.balint and updated branch.