Allow a data-langcode attribute on drupal-media to set the translation. Right now, it always inherits from the host entity's language.
In MediaEmbed::process() add something like this:
// Allow data-langcode to override the translation.
if ($node->hasAttribute('data-langcode')) {
$langcode = $node->getAttribute('data-langcode');
}
TBD
TBD
TBD
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 3075593-4.patch | 3.18 KB | oknate |
| #4 | 3075593--interdiff-3-4.txt | 734 bytes | oknate |
| #3 | 3075593--interdiff-2-3.txt | 2.71 KB | oknate |
| #3 | 3075593-3.patch | 3.55 KB | oknate |
| #2 | 3075593-2.patch | 860 bytes | oknate |
Comments
Comment #2
oknateHere's an initial patch that worked for me when testing manually. Adding "Needs tests" tag. I'll work on test coverage for this when I get a chance.
Comment #3
oknateAdding test coverage.
Comment #4
oknateRemoving a line I added that was no longer needed. Originally I was going to test with another language.
Comment #5
wim leersI intentionally did not port
data-langcodefrom https://www.drupal.org/project/entity_embed to core'sMediaEmbedfilter in #2940029: Add an input filter to display embedded Media entities, because it'salttext on image media or the fallback text for HTML5 video media or the title of document media.langattribute for WCAG 3.1.2 Language of Parts compliance. Just like the https://ckeditor.com/cke4/addon/language plugin lets you do for arbitrary text, which was added to Drupal 8.1 in #1993928: Language of parts: Introduce a language toolbar button. Arguably this should be integrated with that instead: that should let you choose the language of the embedded media, and not the dialog in #2940029: Add an input filter to display embedded Media entitiesComment #6
gábor hojtsyI agree that this would be extra complexity that is probably not needed for the 80% use case. There may be edge cases when someone wants to embed media of another language in an entity but that sounds highly atypical unless I am missing something.
If for some reason we should really have this on the api then we could add support for the attribute (and tests) but not expose it on the UI. Then an advanced use case can alter the form to support it but it would be crowd the form by default.
Comment #7
wim leersGreat.
FWIW: as soon as there is interest in this functionality by at least 10 people, I'd be happy to write a contributed module for this.
For now, marking this as a postponed feature request, because we have consensus this is not widely used enough to justify adding the additional code and maintenance work to Drupal core.
Comment #8
wim leersActually, we usually mark this . Doing that here too.