Problem/Motivation

To enable content translation, one uses the form at admin/config/regional/content-language. This form is very deep and complex if a lot of content bundles are enabled for translation but initially starts off very simple.

Before the age of recipes, when this form was built, the assumption was that you manually created fields and did not yet have them configured for translation. When creating/editing fields, you can't change the translatability until translation support is enabled on the fields.

But extensions and recipes can ship with fields that have their translatability already preset prepared for a time when the user decides to enable translation. For such a case the field editing UI looks like this. Note the translatability checkbox is disabled but is turned on already as this field came from a recipe that had it pre-enabled.

However the form does not assume that there are useful presets for this setting and when enabling the bundle for translation, it has JS to force-enable all the fields to translatable. This made sense when we assumed the fields were hand-created but now that users may have them installed with an extension or applied from a recipe, we should keep the guidance from the config and not overwrite this.

Steps to reproduce

  • Install Drupal CMS with Haven.
  • Enable Content translation.
  • Go to admin/config/regional/content-language and start enabling bundles for content translation.
  • Note that the field translatability presets from Haven are ignored and everything gets checked instead.

Proposed resolution

Do not autocheck the field translatability checkboxes. Consider if we should detect whether the information in the fields was intentional or not. Not sure how we could do this though.

Remaining tasks

User interface changes

Field translatability in the form will just take/keep whatever it was in config already instead of being force to all-checked.

Introduced terminology

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
Screenshot 2026-06-26 at 13.36.23.png453.1 KBgábor hojtsy
Screenshot 2026-06-26 at 13.38.55.png360.78 KBgábor hojtsy

Issue fork drupal-3606544

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:

About issue forks

Comments

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

gábor hojtsy opened merge request !16152

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Active » Needs review

This is a one line JS fix that still works :)

thejimbirch’s picture

thejimbirch commented
Status: Needs review » Reviewed & tested by the community

The change makes sense to support recipes and working in the UI. Moving to RTBC.

jose reyero’s picture

jose reyero commented

This makes a lot of sense, looks good, +1

godotislate made their first commit to this issue’s fork.

godotislate’s picture

godotislate
he/him
commented

I applied the MR diff to main and tested using the form at admin/config/regional/content-language without using recipes:

  • Install with Standard profile
  • Create content type
  • Add a text field to content type
  • Install Content Translation
  • Go to admin/config/regional/content-language
  • Check "Content"
  • Open “Content” details
  • Check “Translatable” for the content type
  • Observe that the "Translatable" boxes for all the base fields get checked, but the configurable text remains unchecked

This is occurring because in FieldStorageAddForm::setTempStore, the field config translatable value is set to FALSE, with the comment // Field translatability should be explicitly enabled by the users.

On HEAD, the checkbox for the field gets checked, so this is a change in functionality when a site is set up this way. Is this acceptable? For a content type with many fields, this could mean the admin/user would need to check quite a few boxes. Though maybe this is mitigated if most sites have a mix of translatable and untranslatable fields and boxes would need to be unchecked anyway?

godotislate’s picture

godotislate
he/him
commented
Status: Reviewed & tested by the community » Needs review

NR for #7. This can go back to RTBC if we think the change is fine.

pameeela’s picture

pameeela commented

I think weighing up the two scenarios, we should preference the one where useful defaults are provided with intent and respect those. If you've built the site from scratch then you'd be in a position to decide pretty easily which fields should be translated, and checking the boxes once each doesn't seem like a huge burden to me?

But it would be good to get some folks who are building a lot of multilingual sites to weigh in on this.

If it is a problem, we could mitigate #7 by adding a 'Select all' option? Unfortunately this form is already a nightmare so I'm torn between "it's already bad so what's another checkbox" and "let's not make it even more complicated".