field storage config should document what it means for translatable to be FALSE

added a patch and To improve the documentation for the FieldStorageConfig class, add a more detailed description of what the translatable property does and what it means when it's set to FALSE.

+++ b/core/modules/field/src/Entity/FieldStorageConfig.php
@@ -129,7 +129,9 @@ class FieldStorageConfig extends ConfigEntityBase implements FieldStorageConfigI
+   * language on a multilingual site. If FALSE, the field is not translatable and
+   * will have the same value for all languages.
    *

My point though is that AFAICT this NEVER gets set to FALSE. There is no UI for it, and fields get created with it set to TRUE.

This needs input from people who know the deep innards of the translation system.

Could this be the default value, when "Adding an existing field" to a content type?

Hey @weseze,
Answer to your question is No, this is not the default value set when "adding an existing field" to a content type. The translatable flag is a property of the field storage, not the field instance. This means it is defined once when the field is originally created and applies globally to that field across all bundles (content types, for example).

When you add an existing field to another content type, Drupal uses the existing FieldStorageConfig definition, including its translatable setting. So the value of translatable is inherited from the original field storage configuration and cannot be changed for each individual instance.

Adding a patch to update the doc block for translatable in FieldStorageConfig.

While the default is usually TRUE, it can be explicitly set to FALSE during field creation (especially via code). Once set, the value is fixed and governs the behaviour across all field instances — the “Translatable” checkbox at instance level has no effect if the storage is non-translatable. Thanks.

It can be changed on a per instance basis... The config file for a field instance allows this. Also the translation interface for for example node-types > fields allows this.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)