Problem/Motivation

When reusing an existing paragraphs field on a non translatable content type the the "Users may translate this field" checkbox is disabled and checked by default. This results in having translatable ERR fields.

Proposed resolution

Set default to unchecked when the field is disabled.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#2 translatable-disabled-default-3110954-1.patch5.28 KBprimsi

Comments

Primsi created an issue. See original summary.

primsi’s picture

primsi commented
Status: Active » Needs review
StatusFileSize
new translatable-disabled-default-3110954-1.patch5.28 KB

Status: Needs review » Needs work

The last submitted patch, 2: translatable-disabled-default-3110954-1.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented
Priority: Normal » Major

At least major... maybe critical.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented 
+++ b/paragraphs.module
@@ -135,6 +135,11 @@ function paragraphs_form_field_storage_config_edit_form_alter(&$form, \Drupal\Co
 
+  // Set the "Users may translate this field"  to be false if disabled.
+  if (isset($form['translatable']['#disabled'])) {
+    $form['translatable']['#default_value'] = FALSE;
+  }
+
   if (!\Drupal::hasService('content_translation.manager')) {
     return;
   }

Slightly confused right now.

First I thought this might be something weird/inconsistent in core when you add new/existing fields.

Then I thought, no it's just because we don't go below the service check, but then I saw that there we just display the message and never change the value at the moment.

Also, I think this is now doing it for _all_ fields, not just our own, so we need to split up the existing check below and check for the field type/target first.

But, lets go one step back and check what the behavior in core is exactly, without paragraphs enabled at all, on a single text field. 4 cases: adding a new text field vs. existing one, having content_translation enabled & active vs not. What is the default value/status/visibility of this checkbox in each case?

primsi’s picture

primsi commented

Fresh install, enabled locale and language, no paragraphs.

No content translation:

checkbox doesn't appear

Content translation enabled:

  • Content type untranslatable - new field: checkbox disabled, unchecked
  • Content type untranslatable - existing field: checkbox disabled, checked
  • Content type translatable - new field: checkbox enabled, unchecked
  • Content type translatable - existing field: checkbox enabled, checked

Seems like this logic was added here #1831608: Show or hide the "Make field translatable" checkbox on the add field form depending on translatability

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Created #3111550: Test that new fields are translatable when re-using existing storage but not translatable when added from the UI