Problem/Motivation

In a multilingual site, when creating media items via the media library widget, the created media items do not always have the same langcode as the parent entity through which they are created. The media library widget simply creates a media item without specifying a langcode, which makes the langcode default to the sites default langcode.

Since users add an alt text in the language of the parent content, this can be problematic.

Steps to reproduce

  1. Setup a multilingual site.
  2. Add a media field to a content type with the media library widget.
  3. Create a translation for existing content, or new content in a non-default language.
  4. Add a media item to the content using the media library widget.
  5. Observe that the created media item has the default langcode, instead of the langcode of the content through which it was created.

Proposed resolution

Pass the langcode of the parent entity to the media library, and use it to create new media items.

Remaining tasks

Write patch
Add tests
Review
Commit

User interface changes

None

API changes

A new optional langcode parameter is added to AddFormBase::createMediaFromValue. It is a protected method, but media library add forms extending the class might need to be updated.

Data model changes

None

Release notes snippet

Issue fork drupal-3450772

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

seanB created an issue. See original summary.

seanb’s picture

Status: Active » Needs review

Created a MR. Let's see if this breaks anything.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

Makes sense to me.

Can we add a test case to show that behavior?

Thanks!

vidorado made their first commit to this issue’s fork.

vidorado’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests

First of all, congratulations to @seanb! The media library code was not trivial, and their fix was both well-executed and clean.

After manually testing, I noticed that the langcode was not being properly set in the translation add form. To fix this, I modified the code to retrieve the langcode from the form_state storage, which turned out to contain the target translation’s langcode.

Since the documentation states that "no specific support is provided for it in the Form API" regarding the FormState::storage variable, I added a fallback to the original fix $entity's language, which is for sure always available:

  $form_state->get('langcode') ?? $entity->language()->getId(),

Additionally, I’ve included an FJ test. :)

smustgrave’s picture

Status: Needs review » Needs work

Left some comments on the MR

thanks.

vidorado changed the visibility of the branch 11.x to hidden.

vidorado’s picture

Status: Needs work » Needs review

Addressed! :)

smustgrave’s picture

Status: Needs review » Needs work

left some comments on the MR.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.