Media ContentTypes Localization enhancements

[HermesSbicego-Laser]

As per Taxonomies, ContentPickerFields and others contents (see #7352) we should consider to enhance localization of media's Content Types (Image, Documents, etc).
By now if you have a multilanguage site and you want to seriously manage SEO and w3c recommendations you have to do a lot of manual tricks in order to manage alternate textes, title, etc... (You have to upload a new media - even if it is the same of the master content - and then you can manage the media alt, title, etc)

I have some ideas on how we could manage it.

A feature "Media Localization Extensions"

1. It adds a LocalizationPart to interested Content Types (I have to go deeper in code to understand where it would be better to add it).

• Translating a "Media" should clone the media file too? I think yes, it should. What do you think?
• In the list of media we should put in evidence the language of that media in order to not mislead the user.

2. It adds a Setting "Localize media on translating" to all MediaLibraryPickerFields (default is true). When a content - which contains a MediaLibraryPickerField - is translated and the setting is true

• all the medias already translated will be replaced with their translation
• all the medias not trasnlated will be cloned, so user can write the translation of textes.
• The Localization of Content and its medias should stay always in sync

@sebastienros @MatteoPiovanelli-Laser @jersiovic @BenedekFarkas @urbanit What do you think?

[MatteoPiovanelli-Laser]

A couple comments to add to that.

Regarding cloning the actual files:
I don't know about that. Maybe they are already managed in such a way that there would be no need for that. On top of that, not al media have a corresponding file in storage.

Regarding the fields:
Basically what we did for ContentPickerField, so I don't see any issue there.

[sebastienros]

I don't think media files should be cloned. But there needs to be a way to change which file is attached if the translation needs a different one.

[sebastienros]

Otherwise I don't see how localization should be different than another content item for media. Some fields should be synced, content should be cloned, ...

[BenedekFarkas]

Yeah, I agree, the files themselves should not be cloned (at least initially), so basically the MediaPart.Path property is translation-independent - I think what matters most here is the title (caption), which should also be cloned, but can be changed (translated).
Although the idea that the files could also be independent across translated versions sounds interesting (e.g. they might have a specific flag (even literally) or some other, language/country-specific feature on the image), but I think that brings us to a bigger question: Should it be possible during editing a Media item to change the actual file in the storage in points to? On a related note, I usually associate Media items with Images at first glance, but actually if you're thinking about documents, it totally makes sense to have the localized versions point to different files - in that case, there should be a generic way to edit the item and select/upload another file (or files).

[MatteoPiovanelli-Laser]

I think handling the actual media, be it a file or whatever, is the actual crux here.
It will be images, videos, documents, oembed content. And ideally there should be a single interface handling all of that, independent of media type and storage.

I don't know in detail what is going on there at the low level, so I will need to look into it before being able to say more.

[HermesSbicego-Laser]

@sebastienros @BenedekFarkas @MatteoPiovanelli-Laser Working on it in these days. When I will have a base working version I will demo it, cause I have some doubts (not blocking for now) to discuss with you.