Currently, the Content Translation Controller generates a table to display the status of translations for a content entity.
Because this is not rendered in a form, there is nothing to hook into in order to modify this form; so changing the content of the Translate page is only possible by altering the route for the following method:
\Drupal\content_translation\Controller\ContentTranslationController::overview
When more than one contributed module does this, the modules are no longer compatible and so become mutually exclusive. It would be good for the Lingotek module, the TMGMT module, and any other module that would like to modify translation pages for content entities to be able to do so without having to exclude each other in a given Drupal instance.
1. Decide on an approach that could let multiple modules modify the page.
2. Write a patch.
3. Review and test.
TBD
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | 2351685-22.patch | 1.26 KB | Gunjan Rao Naik |
| #16 | 2351685-16.patch | 2.58 KB | hchonov |
| content_translation_table.png | 23.94 KB | robertdbailey |
Show commandsStart 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:
compare
Comments
Comment #1
jhedstromI think this is arguably a task, not sure if it could still get into 8.0.x or not though.
Comment #2
plachAsked @WimLeers to provide feedback on this.
Comment #3
wim leersFor entities, we have
hook_entity_view_alter(), for blocks, we havehook_block_view_alter(), for Views we also have alter hooks.But this is just a route whose controller returns a render array.
Seemingly the only way you can currently override it is by replacing the controller, as plach pointed out, and that's a problem as soon as >1 module wants to do that.
But there's one more way :) A
KernelEvents::VIEWevent subscriber that does ais_array($response) && $route_match->getRouteName() == 'the route name'check, and then modifies the render array in$response.Comment #4
fabianx commentedI think a hook would be better than the KernelEvents::VIEW.
The overall out solution would be to have a plugin manager that calls plugins as a chain-of-responsibility.
The simple way is to have a supported alter hook and then can use e.g. #pre_render callbacks ...
Though I must admit that KernelEvents::VIEW also would support adding just to #pre_render, which probably would be fine then ...
Edit to clarify:
My main concern with using a generic hook like Events::VIEW for doing something specific is that if everyone does that then ordering issues occur, while for a specific hook to alter e.g. the table, the modules could negotiate on and around themselves and then the generic ::VIEW would work like normal.
Comment #16
hchonovA small patch that adds a hook. I do not think that we need to convert the controller to a form since the major place that might require some changes by other modules is the render array of the content translation overview. I've also made one further change to use the langcode as a key for the rows instead of numeric values so that it makes it possible for developers to easily identify the rows for the translations.
Comment #17
joachim commentedLooks like #3227102: Content Translation Overview Controller - make overview table easier to extend duplicates this.
Comment #18
antoniya commentedHi @hchonov, why is this check for German language in the patch?
Comment #20
anup.sinha commentedHi @hchonov, Can you please reply to Antoniya's question why a condition for a specific language.
Also I think this should be a high priority task as currently we don't have any option to alter the translate overview table. This is really a blocker if we want to add a button for any content translation service or do any modification into that table.
Thanks & Regards,
Anup
Comment #21
anup.sinha commentedHi @All,
I have validated the latest patch and the newly created hook is not working. I have implemented the new hook in my custom module and getting the below error -
[03-Feb-2023 12:36:33 Asia/Kolkata] Uncaught PHP Exception Error: "Cannot use object of type Drupal\Core\StringTranslation\TranslatableMarkup as array" at C:\wamp64\www\drupal-10.0.0\modules\custom\content_view_alter\content_view_alter.module line 14
Line #14 - "if (isset($column['data']['#type']) && ($column['data']['#type'] === 'operations')) {"
Also whenever a new hook is created, please add a new test for it as the code added in api.php will have not be executed until we are implementing it. So it's very important to have a test for any hook. Changing the ticket status to Needs work.
Thanks & Regards,
Anup
Comment #22
Gunjan Rao Naik commentedAdded patch against #16 in 10.1 version
Comment #24
smustgrave commentedClosed #3227102: Content Translation Overview Controller - make overview table easier to extend as a duplicate
Comment #25
sonfdhttps://www.drupal.org/project/drupal/issues/3227102 also gave columns non-numeric, descriptive keys, see patch #2 from that issue. +1 for doing that here too.
Comment #26
miiimooo+1 from me for this patch.
I have added an example project that is useful when there are many languages installed on a site here https://www.drupal.org/sandbox/miiimooo/3414705
The project depends on this patch at the moment
Left Todo:
* Document in content_translation.api.php
Comment #27
miiimooo