Problem/Motivation

Drupal Canvas uses a base field to store component data (tree and inputs). These two are normally separately configurable for translation. But Drupal core content translation uses third party settings config to verify existing settings and base fields to not carry third party settings until a base field override config is saved that can contain them. So the option to separately configure the tree and inputs for translation only shows up once the user saves the components field at least once untranslatable altogether. Then base field overrides get saved for it (because by default it is translatable, so keeping it translatable does not result in a base field override needed). Then we can see the options.

Steps to reproduce

  • Install Canvas and all core translation modules (Canvas dev translation module is not needed).
  • Go to admin/config/regional/content-language, note you don't have the tree and inputs options at first.
  • Fiddle until you figure out you need to save it untranslatable at least once to be able to disable tree translatability.

Proposed resolution

Change the form builder to consider the base field configuration until there is a third party setting to build the settings.

In core, this already affects the Media entity’s translatable base field thumbnail.

Remaining tasks

Review.

User interface changes

"Column groups" / "subfields" will show up for base fields on the content translation form immediately instead of needing to do awkward things.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

Not needed IMHO.

LLM disclosure

LLM was used to analyze this problem, devise a fix and write tests. The output / proposal was human reviewed and is recommedned as a human though :)

Issue fork drupal-3606969

Command icon Show commands

Start 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:

Comments

gábor hojtsy created an issue. See original summary.

gábor hojtsy’s picture

This is the problem on a video:

gábor hojtsy’s picture

Issue summary: View changes
Status: Active » Needs review

Added suggested fix with tests. Used LLM so adding LLM disclosure.

gábor hojtsy’s picture

Issue summary: View changes
StatusFileSize
new432.14 KB

Adding screenshot to make it easier to see without the video even.

gábor hojtsy’s picture

Issue summary: View changes

Link image for bigger watching.

gábor hojtsy’s picture

Issue summary: View changes

Core media is also affected via the thumbnail field. The test covers that (and proves that it fails without the fix), adding that note to the issue summary.

penyaskito’s picture

Status: Needs review » Reviewed & tested by the community

I saw the same problem, and got to the exact same fix.

As you can see there are no changes to the form submit handler, because it was already adapted for this. This processes the base field definitions in the same way for the form creation itself.

wim leers’s picture

  • longwave committed b11b664b on 11.4.x
    fix: #3606969 Content translation column group settings only show up...

  • longwave committed 23559ca6 on 11.x
    fix: #3606969 Content translation column group settings only show up...

  • longwave committed 68f6b308 on main
    fix: #3606969 Content translation column group settings only show up...
longwave’s picture

Version: main » 11.4.x-dev
Status: Reviewed & tested by the community » Fixed

Committed and pushed 68f6b308eae to main and 23559ca6e15 to 11.x and b11b664bba3 to 11.4.x. Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

alexpott’s picture

Status: Fixed » Needs work

This change causes a regression in configuration schema. Entity usage tests are failing on the next minor have started to fail after this was merged and a git bisect proves it - see https://git.drupalcode.org/project/entity_usage/-/jobs/10639671 - specifically the failure for \Drupal\Tests\entity_usage\FunctionalJavascript\ListControllerTest::testListController on line 206. This is where we've done

    // Set our content type as translatable.
    $this->drupalGet('/admin/config/regional/content-language');
    $page->checkField('entity_types[node]');
    $assert_session->elementExists('css', '#edit-settings-node')->click();
    $page->checkField('settings[node][eu_test_ct][translatable]');
    $page->pressButton('Save configuration');

If I add

  /**
   * {@inheritdoc}
   */
  protected static $configSchemaCheckerExclusions = [
    // Mising schema for:
    // - core.base_field_override.media.eu_test_image.thumbnail:third_party_settings.content_translation.
    // @todo fix in Drupal core.
    'core.base_field_override.media.eu_test_image.thumbnail',
  ];

to the test it passes.

penyaskito’s picture

That's #3387100: Missing config schema for core.base_field_override.*.*.* third_party_settings.content_translation :-(

Canvas also uses configSchemaCheckerExclusions for avoiding this issue

alexpott’s picture

Yep #3387100: Missing config schema for core.base_field_override.*.*.* third_party_settings.content_translation is the fix. What has changed here is that any save on the form with media installed now breaks in a test whereas before it did not.

alexpott’s picture

Okay the other issue is RTBC - let's go forward rather than backwards.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.