After exposing media image's name field and translating it, it gets overwritten by the default field mapping.

I think this is more a matter of explaining behaviour than actually changing it.

1. We could add a message to mapped fields, explaining their values would be overwritten. Since editor can't do anything about it this is probably not preferable.
2. We could also add some message to the form display page. When site builders expose a mapped field, a warning could be added explaining the behaviour.

I would personally prefer option 2.

While saving we only update the metadata when a field is empty or when the source field changes:

// Only save value in entity field if empty. Do not overwrite existing
// data.
if ($translation->hasField($entity_field_name) && ($translation->get($entity_field_name)->isEmpty() || $translation->hasSourceFieldChanged())) {
  $translation->set($entity_field_name, $media_source->getMetadata($translation, $metadata_attribute_name));
}

For a new translation the source field is changed, so then it will overwrite the mapped fields. If you would try to change the title of the translation a second time it would probably work until you change the source field again.

It is still not a good idea to expose mapped fields imho.

It's OK for a site builder to un-map the name field if they want to, right? Then authors would always have to provide the name manually.

It's OK for a site builder to un-map the name field if they want to, right? Then authors would always have to provide the name manually.

That is definitely OK! I have built sites that do exactly that myself. We wanted a super easy form out-of-the-box so we mapped the name field by default, but removing a mapping is no problem at all.

> It is still not a good idea to expose mapped fields imho.

Well, if that's not recommended, then what's the point of even having it translatable :) That will make it even harder to distinguish translations on the table overview?

I still think that the approach that we're working with, which only fills the name field when it was empty instead of an "enforced" mapping is a better solution for the media name.

Well, if that's not recommended, then what's the point of even having it translatable :) That will make it even harder to distinguish translations on the table overview?

It depends, if the source field is translatable it could still fetch the title from the media source. For example youtube video's uploaded in multiple languages with a custom title for each one. If we only overwrite empty titles or not allow translations for mapped fields the translated video would not get its title updated.

In the current implementation, mapped fields should not be manually changed. I'm open to changing that, but that would complicate the behaviour of mapping. It might be better to just explain what the mappings do and warn users exposing mapped fields.

> In the current implementation, mapped fields should not be manually changed. I'm open to changing that, but that would complicate the behaviour of mapping.

That's also how the configuration in standard works and I agree that umami should then decide if it either wants to happen and if so, hides the field.

But I still think that's problematic in a multilingual context, when we show all translations in the list.

> It might be better to just explain what the mappings do and warn users exposing mapped fields.

The limitation is that core currently black & white. Either you map, the you must hide the field, or you dont' and show it but then it is required and users are forced to provide a name manually.

As mentioned in the issue that made this the default configuration for standard, what we do instead in our install profile is a form alter that makes the fields optional and then rely on the fallback logic instead to fill it out. But that *only* happens initially and if it's empty.

A fancier version of that would be to implement that in javascript somehow, of course not trivial to do that generically.

Probably a major bug given the lost user input (however we address it).

I'd say if bug, then "only" in umami, to hide the media field, and I think that's only in the not-yet-committed umami/media patch?

That is the behavior that was chosen, as (optional, since media is not yet required) default configuration in standard, so I think as a minimum step, umami would just need to be kept in sync with that.

The things I'm talking about is probably a feature.

I would say the behaviour makes sense. I would consider it a bug if a source field was mapped and the title was not updated.
That being said, I agree this behaviour is not intuitive and we could improve this by warning users when they expose mapped fields in forms.

Sounds like we need to decide

- if this is a bug
- is it only a bug in umami
- what can we do to prevent site builders getting into this mess
- do we want a feature request to support the ideas from #11

We are also experiencing this behavior during a migration of media items (Core version 9.3.x) so I wouldn't say it's related to Umami only.
Each translation has a different image attached to the media item. When saving the entity (MigrateExecutable::import() -> Media::prepareSave() the translated name set by the migration is overridden by the file name of the source file (because Media::hasSourceFieldChanged() returns TRUE).

We (kind of) solve this right now by adding an additional presave hook that sets the name back to its correct value.

--Update

Seems like skipping the "Name" field in the field configuration of the media source fixes the problem for us (see https://www.drupal.org/project/drupal/issues/2999370#comment-13055698).

Should this be reopened per #22?

This bug report looks like a duplicate of #2999370: Mapped media fields are overridden with metadata on translation save so maybe this issue could be re-scoped to address what we can do to prevent site builders getting into this mess.

- if this is a bug
- is it only a bug in umami
- what can we do to prevent site builders getting into this mess
- do we want a feature request to support the ideas from #11