Add content_translation support

I came across this issue looking for a similar solution to allow content authors to manage media translations from the referencing content.

@rstroh, what exactly did you try when you said the following?

Enable to switch tabs on the modal too

There is discussions within Drupal core issue queue about editing media and translations.
See #3266293: Media items translate items in modal and #2985168: [PP-1] Allow media items to be edited in a modal when using the field widget

I'm wondering if Media Library Edit can be extended to support a solution like that proposed in #3266293: Media items translate items in modal

Thank you for reporting and working on this issue!

From an UX point of view, it seems to me that if I'm on the french version of a content form and click on the edit link of a referenced media, I expect to see the form to edit the french version of the media (or add that translation if it does not exist). And likewise, if I'm on the english node form, the modal should show the english media form.

(With a special case if the referenced media is not translatable: then it should show the only media edit form available)

I had a quick look at the code, it seems the main place for changes is around here: https://git.drupalcode.org/project/media_library_edit/-/blob/3.0.x/media... so that $edit_url is the right one according to the content form's language and the media translation state.
For example, for an existing referenced media in french, with no existing english translation, the url should be something like /fr/media/42/edit if I'm on /fr/node/1/edit, but /en/media/42/translations/add/fr/en if I'm on /en/node/1/edit. Or if the english media translation already exists, the url should be like /en/media/42/edit.
And probably some code here: https://git.drupalcode.org/project/media_library_edit/-/blob/3.0.x/media... to remove the language field on the media form when in the modal.

@rstroh

I'm not sure if your use case #1 is very usual. It would be nice to have this, but it may be a new follow-up issue so that this one can stay quick and simple?

About #2: To me (but I might be wrong of course), if no media translation exists for the current language, you should have no "Edit" button but rather a "Translate" button at the same place that directly opens the media translation form for the current language (not the translations overview).

What do you think?

Thank you for your patch and sorry for the delay!

The patch looks good at first glance but the URLs seem to have the wrong language, and some translation access checks might be nice to have. I opened an issue fork to ease development and discussion, and pushed a fix there, upon your patch.

I handled the case when the translation does not exist yet, but there's still a problem: when I close the modal after saving the new media translation, the form element doesn't get refreshed, so the UI still show a link to add a translation, instead of editing the one I just created.

And it would be nice to be able to have a setting to enable or disable the translation overview link (which requires switch to a dropdown UI). I'd prefer to have it disabled on my websites, to keep the UI clear and simple, with only a little pen icon to edit/translate the media in the current form's language.

https://git.drupalcode.org/issue/media_library_edit-3316163/-/commits/33...

Hello, thank you for the work.
I wondering if we can have this patch for the 3.0.x ?

So I've worked on a patch for the latest 3.x dev version as of today. I think I've gotten everything that was in the issue fork. Patches are attached.

When testing I noticed some layout issues while having GIN and Claro installed on our site. So I've also created a patch for when that happens. Example also attached, So if you have the same issue as us while having GIN as your admin theme, then try that patch or use it as a example if your issue is different from ours.

I updated media_library_edit-3316163 with latest 3.x changes, gin fixes in #14 and a typo in render array 'attached' vs '#attached'.

To test I did the following:

1. translated a node
2. on the edit page for that node I went to the media field. For each media that didn't have a translation, there was a button to translate
3. clicking the "translate" button shows a modal and allows for editing the translation.
4. saving the node and inspecting the image shows the translated translation
5. reviewing the entity at /admin/content/media confirms that there is a translation

Note: On Gin theme the dropdown button active state looks a bit off:

Accidentally created a new issue #3383759: Error: Call to undefined method Drupal\field_ui\Form\FieldConfigEditForm::getFormLangcode() in media_library_edit_field_widget_single_element_form_alter() (line 123 of modules/contrib/media_library_edit/media_library_edit.module), when the cause was this issue. The patch on #14 needs something like:

--- a/media_library_edit.module
+++ b/media_library_edit.module
@@ -17,6 +17,7 @@ use Drupal\Core\Field\WidgetInterface;
 use Drupal\Core\Form\FormStateInterface;
 use Drupal\Core\Routing\RouteMatchInterface;
 use Drupal\Core\Url;
+use Drupal\field_ui\Form\FieldConfigEditForm;
 use Drupal\media\Entity\Media;
 use Drupal\media_library\MediaLibraryUiBuilder;

@@ -116,6 +117,9 @@ function media_library_edit_field_widget_single_element_form_alter(array &$eleme
       $element['#attributes']['class'][] = 'js-media-library-edit-' . Html::cleanCssIdentifier($context['items']->getFieldDefinition()->getName()) . '-wrapper';
       /** @var \Drupal\Core\Entity\ContentEntityFormInterface $form_object */
       $form_object = $form_state->getFormObject();
+      if ($form_object instanceof FieldConfigEditForm) {
+        return;
+      }

I couldn't install the patch on Drupal 10.1.2 on 3.0.2
I don't know if it's related to #19

I've added the changes from #3062091: Add option to select form display mode. Which adds the option to set the form_mode.
Tested it on our local environment and seems to be working fine.
This should make it work on the latest dev branch.

we will still have to look at the problems in comment #18. with the allignment.

and I also haven't looked into #19 yet.

Here is the patch, because the MR needs to be updated first. @robpowell could you update your MR to target the dev branch origin/3.0.x ? I don't seem to be enable to do so, I could create a new MR, but that wouldn't be the best option IMO.

Added the remaining tasks. We found out a new issue with the patch (22): the Body field WYSIWYG (CKEditor 5) buttons disappear after editing&saving the translated media item alt-text in dialog. I can reproduce the issue with 10.1.5 and 10.2.x, and removing the patch (#22) will fix the issue.

Have been trying to debug the CKEditor field converting into plain textarea after submitting the media field translation dialog.
What I have tried so far:
- Drupal with different core versions (9.5.x, 10.1.6, 10.2.)
- Switch the WYSIWYG field to use CKEditor 4
- Hardcoding the core/ckeditor5 dependency to module and #attached libraries.

Once this is resolved I think it would greatly help to tackle the regression if we could add the tests. Wrote the manual steps how to reproduce the issue.

composer require drupal/admin_toolbar drupal/media_library_edit:3.0.x-dev drush/drush
vendor/bin/drush en content_translation media_library_edit media_library -y
cd modules/contrib/media_library_edit
curl -O https://www.drupal.org/files/issues/2023-09-11/3316163-22.patch
patch -p1 < 3316163-22.patch
# Add a new language
http://localhost:8888/admin/config/regional/language/add
# Allow translating node:article
http://localhost:8888/admin/structure/types/manage/article
# Allow translating media:image
http://localhost:8888/admin/structure/media/manage/image
# Create a new media reference field with media:image
# Make sure "Users may translate this field" is checked
http://localhost:8888/admin/structure/types/manage/article/fields/add-field
# Make sure "Show edit button" is checked on Media field
http://localhost:8888/admin/structure/types/manage/article/form-display
# Add a new article and add media:image
http://localhost:8888/node/add/article
# Translate the article and edit the media field.
# After submitting the media dialog, the CKEditor field changes to plain textfield.

For anyone looking a temporary solution with WYSIWYG editor disappearance, I've created a following core patch.

I decided to create a new branch and MR based on the existing MR. I didn't make any changes.

I've merged the changes from the latest commit on the Dev branch.

I excluded the part for the FormattableMarkup as we display it different, also it creates a visually hidden span element, which makes it obviously visually hidden.

patch #14 (gin version) applies ok on media_library_edit 3.0.3 and D 10.2.5 but creates another issue ( see #19)

Unfortunately MR17 patch is not compatible with 3.0.3 :/

I hope a new release will be published soon, This is such an essential feature imo.

@daisyleroy If you would like to use the MR, you would have to use the dev branch for media_library_edit, as it is one change ahead of the release tag.

I do have to say, we experienced some visual bugs with the MR like in #18. So some work on styling has to be done first imo.

@Arantxio I tried the MR17 but the patch fails to apply (I'm using core 10.2.6):

I executed this command to get the 3.0.x version which is the target branch of MR17:

composer require 'drupal/media_library_edit:dev-3.0.x'

Then I added the patch like this:

"drupal/media_library_edit": {
   "Add content_translation support": "https://git.drupalcode.org/project/media_library_edit/-/merge_requests/17.patch"
 }

But composer gives an error:

Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/media_library_edit/-/merge_requests/17.patch

MR17 was based on 3.0.2, and the merge with 3.0.x did not work out apparently.

This is the commit which conflicts: https://git.drupalcode.org/project/media_library_edit/-/commit/3258d004d...

I've update the MR to be based back on the 3.0.x branch, which should work no problem, as we have been using it for some time.
The dev branch can be checked out as followed:
"composer require 'drupal/media_library_edit:3.0.x-dev@dev'"

Here is the current git tree:

And how its set within our composer file:

I've also created a patch based on #14 but then for 3.0.3 and with the fix mentioned in #19, hope this helps

The patch didn’t apply to version 3.0.4 or the dev branch, so I created a new one based on comment #35.
I also added a new class to the dropdown element to make it easier to target with CSS for the Gin theme.

not sure what the issue with patch from https://git.drupalcode.org/project/media_library_edit/-/merge_requests/17 is?

manually rolling the patch with:

git diff 3.0.x 3316163-add-contenttranslation-support-2

applies without issue.

We also faced the situation that the patch could not be applied. Maybe a whitespace or line ending chnage that is not visible?
Anyway, here's an adjusted patch that is working with composer.

we ran in to an issue when editing a node where no translation exists (eg de/node/123/edit when there is no de translation) that links to media that is translated (eg de/media/345/edit does have a de translation).

while the translated media is rendered, the edit link will use the form language rather then the translation language (eg media/345/edit rather than de/media/345/edit).

ive created a fork of the patch https://git.drupalcode.org/issue/media_library_edit-3316163/-/blob/33161...

it's a one line change, just not passing the form language to:

              $edit_url = $media->toUrl('edit-form', [
                'query' => $edit_url_query_params,
              ]);

another little change is to get the media from the element rather then manually reloading:

        if ($media = $element['selection'][$key]['rendered_entity']['#media']) {

if that sounds ok(?) i'll merge into the PR.

https://www.drupal.org/files/issues/2026-02-17/media_library_edit--SHA-e...

None of the patches nor the MR apply to 3.0.5

Patch for 3.0.5.

The patch in #45 applies cleanly to 3.0.5, but does not resolve the issue.

Instead, download the patch from the merge request in #43 (https://git.drupalcode.org/project/media_library_edit/-/merge_requests/1..., I use 'plain diff'), and apply it to the dev version of the module (composer require drupal/media_library_edit:3.0.x-dev).

For me, it is also helpful to have the patch for the Gin theme to correct the positioning in #3316163: Add content_translation support.