For sites that have made layout overrides prior to 8.7.0 or sites that manually enable translation of the layout override field, add UI warnings

We have a few options:

• Alter in a confirmation form when the user enables translation for an LB field. E.g. "Translating layouts is not currently supported and enabling translation on this field may have unintended consequences." Or something.
• Display a DM on the content translation configuration page for the same.
• Add a status report notice similar to the JSON:API one if the user has this field translation enabled (possibly with additional warning if the field actually contains data). @webchick was -1 on this but I think it merits discussion.

I think this also applies to sites that might try turning this on in the future, since we're not disallowing it, only changing the default. I'd want those sites to see a warning that says "Enabling translation of this field won't do what you think it's going to."

I think this also applies to sites that might try turning this on in the future, since we're not disallowing it, only changing the default.

For entity types with no existing bundles using layout overrides, we're able to set it to untranslatable at the $field_storage level, which means it's not shown in the CT config form at all. No checkbox to enable, so no way to "try turning it on". Per #4, they'd have to do a config export, manually edit the YAML, then import those manual changes. I don't think we should cater to that.

But, for entity types with existing bundles using layout overrides, when layout overrides are added to a new bundle, we can only set that to untranslatable at the $field level, and therefore, that does show up in the CT config form as a checkbox that's unchecked but can be checked.

Right, it's the second part of #5 I'm concerned about. Any site that has overrides is like a carrier of a disease for this problem, even if they don't use Content Translation already.

@effulgentsia Maybe you could add STR to the IS showing the problem in that case? I think it's something like:

1. Install 8.6. Enable Builder but not Content Translation.
2. Enable layout overrides for articles.
3. Update to 8.7. Merrily going along adding layout overrides because LB is a great tool! You don't know anything is wrong.
4. A year from now, when any release notes or CRs from 8.7 are long forgotten, enable Content Translation, because you're getting enough business that the CEO says you should add English version of the content.
5. Install a second language at admin/config/regional/language.
6. Enable translation for node content at /admin/config/regional/content-language.
7. Mark Articles as translatable. Note that the translation checkbox for Layout is checked by default.
8. Click "Save" because you have no way of knowing there's anything wrong with the defaults you just enabled.

I'm going from this in the CR:

For sites that enable Content Translation at a later time
Sites that had layout overrides enabled before 8.7.0 and some time later enable the Content Translation module should follow the steps above to set the layout field to non-translatable.

Here's another scenario I'm concerned about:

(Advance apologies to all the francophones for the typo in "ceci" in the screenshots.)

1. Check out f1e6647a323 or anything earlier on 8.7.x. EDIT: Per @tedbow, the following scenario is the behavior of only 8.7.x sites, not 8.6.x ones.
2. Install Standard, Layout Builder, Content Translation
3. Install French (or your language of choice) at /admin/config/regional/language
4. Enable translation of content on /admin/config/regional/content-language
5. Enable layout overrides for articles at /admin/structure/types/manage/article/display
6. Create an article entitled "AMERICA YEAHHHHHH" at node/1.
7. Go to /node/1/layout. This article is so American that a stars-and-stripes eagle should be eating apple pie in a baseball diamond, so add a custom block with an appropriate image. Save the layout.
   
8. Now go to /fr/node/1/translations/add/en/fr and try to take things down a notch. Translate and save.
   
9. Notice the giant American flag at the top of your content. Irritatedly click the layout tab on your page to fix the problem.
10. Delete the "YEAHH AMERICA YEAHHH" block and replace with a nice painting of Notre-Dame.
    
11. Save. That's much better, right?
12. Switch back and forth between the two, editing their layouts. Everything seems to be working fine. You can edit either, and neither updates the other. I tested this over and over and could not reproduce the problem of one overwriting the other.
13. Update to 8.7.x HEAD and clear the cache. Try to edit the French layout. It's stuck there, as-is, forever. There's no information in the UI indicating how to change it. There's nothing on your status report about why this happened. I'm just a content translator; I don't know anything about Drupal updates and it might be months before this problem is actually discovered.

Should a message be put on this page? Status report message about this orphaned layout content? What?

Edit: This particular scenario affects only sites updating from (e.g.) 8.7.0-alpha1 to 8.7.0-beta1, so we'll want to differentiate between the two for the release note. I'll update the original issue accordingly.

@tedbow clarified that the regression in #9 is specific to 8.7.x sites. I'll test from 8.6.x next.

An issue similar to this is addressed in Paragraphs.
Fields of the type Paragraph are non-translatable, but are enabled by default in content translation, so they also need to inform the user that the field is not actually translatable.

A screenshot of the approach can be seen here #2760341: Let the user be aware that Paragraphs fields are not supported for translation
The "(* unsupported) Paragraphs fields do not support translation" message is always present at the top of the Content Translation form. The message is formatted as a warning unless a field of the type Paragraph is set as translatable, in which case it is formatted as an error.

Adding a message to the top of the Content Translation form + appending a warning to the field names seems like it would work here as well, and it would match a pattern that has likely been seen by many users already. I'd prefer if there was some kind of form validation involved so it wasn't even possible to enable translation for the field, but the fact that this validation wasn't implemented for Paragraphs suggests that there were implementation barriers or other good reasons for not including it.

Also note there has been interest in improving this experience in Paragraphs, but it has proven difficult to implement: #2787095: Improvements for translation settings

This is an implementation of how it is approached in Paragraphs. The specifics of the solution for this haven't been fully hashed out yet, but this should be fairly easy to build from. Hopefully any additional changes just require changing the form_alter that is provided here.

Discussed with @dyannenova with @webchick. We've compromised on something like this:

(With the yellow triangle warning icon in place of [!].)

@xjm thanks for posting the image.

Here the 2 options neither is good. Neither is done but wanted to get feedback.

Render array fun

So putting actual html and not plaintext in with the label is very difficult because of what _content_translation_preprocess_language_content_settings_table() it move the different # properties of the form around and puts #label in a #plain_text element and then within that section the $build there is nothing that actually gives us the machine of the field and the input is already rendered so we can't even find it from that

Please observe

So we at least have to make a 1 line change to _content_translation_preprocess_language_content_settings_table() to set the field name to tell which element we need to alter.

here is solution in that manner it is not finished but I would like feedback if this is the way we want to go.

The plain text option

We could just use hook_form_FORM_ID_alter to add a warning to the label but that gets set to #plain_text in _content_translation_preprocess_language_content_settings_table() so we can't have a link.

Here is what I think is better option. Actually using the #description property of the checkbox but then changing _content_translation_preprocess_language_content_settings_table to actually moving it which it should be doing anyways.

I will also add another patch that simply sets #description and then moving it in _content_translation_preprocess_language_content_settings_table could be a follow up.

Basically I feel this last way is correct. But it looks bad because _content_translation_preprocess_language_content_settings_table does take into account that these form elements could have #description

Had to add a whole new library to get the css for this

interdiff is of 3043646-use_description-16.patch

Moved the icon a few pixels down to align with the text in Seven. I also converted the description class to use BEM and fixed #18.

Oops. I was in a bit hurry and accidentally forgot to update the value from Chrome debug tools to the patch.

Here's how this looks now:

That's more or less the spec that @DyanneNova came up with, so looks good.

Ok chatted with @effulgentsia and @tim.plunkett.
We figure out a way to

1. limit our change our change to content_moderation to 1 line
2. remove the need for our hook_form_alter

Yay for small patches! thanks all!

All the PHP code, including the 1 line addition to content_translation, looks great to me.

Leaving the final review for a frontend framework manager.

+++ b/core/modules/layout_builder/css/layout-builder-content-translation.css
@@ -0,0 +1,4 @@
+.layout-builder-translation-warning {
+  background: left 2px url(../../../misc/icons/e29700/warning.svg) no-repeat;
+  padding-left: 20px;
+}

This change looks great for me overall. This CSS is Seven specific. We should add a todo comment here to remember to move this to Seven as part of #3041053: Mark Layout Builder as a stable module.

Fix #27 and fixed link to new online docs https://www.drupal.org/docs/8/core/modules/layout-builder/layout-builder...

Committed a83655a and pushed to 8.8.x. Thanks!

C/p as 7f5a4bc450 and pushed to 8.7.x

+++ b/core/modules/layout_builder/layout_builder.module
@@ -367,3 +367,46 @@ function layout_builder_entity_translation_create(EntityInterface $translation)
+  // Move our preprocess to run after
+  // content_translation_preprocess_language_content_settings_table().
+  if (!empty($theme_registry['language_content_settings_table']['preprocess functions'])) {
+    $preprocess_functions = &$theme_registry['language_content_settings_table']['preprocess functions'];
+    $index = array_search('layout_builder_preprocess_language_content_settings_table', $preprocess_functions);
+    if ($index !== FALSE) {
+      unset($preprocess_functions[$index]);
+      $preprocess_functions[] = 'layout_builder_preprocess_language_content_settings_table';
+    }
+  }

So this doesn't just move it to after content_translation_preprocess_language_content_settings_table(), it moves it all the way to the end, including after theme preprocess functions. I think that's fine. I doubt there's any admin themes preprocessing this table in a way that would fail if the LB function comes after them. But, for anyone interested in there being an API for inserting things into desired positions of an array, there's #66183: Add helper methods to inject items into a particular position in associative arrays and possibly other similar issues.

This patch was committed without a test. Which is fine, given the rush to get it in before beta. However, since it relies on the order in which preprocess functions run and internal details about another module's render array structure, and we may want to refactor it in 8.8.x to something more along the lines of #16, I think it could benefit from a test. Perhaps adding an extra assertion at the end of MakeLayoutUntranslatableUpdatePathTestBase::testDisableTranslationOnLayouts() for whether the warning appears on the form when we expect it to, and doesn't when we don't?