The issue is that content_translation form checks on the #type of the fields. If this is a "vertical_tabs" section, than ignore it and continue.
But the hook_form_node_form_alter() within Claro and Seven change the #type of the vertical_tabs to container.
Therefor the #access is set to false and translateable fields in the advanced sidebar are not editeable. This is done by entityFormSharedElements in the ContentTranslationHandler, which is set as a #process handler after the form alters are done.
Somehow 'advanced' needs to be "ignored" if it contains fields which are translateable.
I though of two options:
1. The themes need to add their own process handler to correct this "issue". Because they break it in a way.
2. Or we need to mark it somehow as multilingual, by incorporating checks on #group when iterating through the elements in content_translation_form_alter().
The first option might be easy, because we could fix this specific issue. But in other cases this might still break (using the field group module, or even in commerce 2.x).
The second option would be the most generic way I guess. By checking the #group when iterating over the field definitions:
foreach ($entity->getFieldDefinitions() as $field_name => $definition) {
// Allow the widget to define if it should be treated as multilingual
// by respecting an already set #multilingual key.
if (isset($form[$field_name]) && !isset($form[$field_name]['#multilingual'])) {
$form[$field_name]['#multilingual'] = $definition->isTranslatable();
}
}
We could check if #group is set. If so, and the #group element exists, set #multilingual true here as well.
Needs work
9.5
Used to track the progress of issues reviewed by the Drupal Needs Review Queue Initiative.
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.
As a bug this will need a test case.
If anyone gets time updating the issue summary to the default template is super helpful for future reviews and the committers
Did not test or review