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.
