Follow up for #1977784: Content language settings configuration page needs to determine what entities and bundles to include


confusing terms: translatable, multilingual, language-aware, untranslatable, non-translatable, not translatable, enable translation, translation enabled/disabled/not enabled
It's confusing in code, code comments, and UI


In the UI, to enable translation, the checkboxes usually are for making it "translatable".

  • admin/structure/types/manage/article/fields/node.article.field_image where parts of the image field can be checked off to be "Translatable elements"
  • admin/config/regional/content-language content language settings page where the header to the column is "translatable"
  • admin/structure/types/manage/article where Translation is "Enable translation"
  • admin/structure/types/manage/article/fields/node.article.body/field-settings is "Users may translate this field."

code and the code comments

the translatable setting is really (imo) whether translation is enabled
and that is set only when something is translatable. things that are not translatable do not have 'translatable' set either way.


   * Boolean indicating whether entities of this type have multilingual support.
   * At an entity level, this indicates language support and at a bundle level
   * this indicates translation support.
   * @var bool (optional)
  public $translatable = FALSE;


 * Defines the node entity class.
 * @EntityType(
 *   id = "node",
 *   label = @Translation("Content"),
 *   bundle_label = @Translation("Content type"),
 *   module = "node",
 *   controllers = {
 *     "storage" = "Drupal\node\NodeStorageController",
 *     "render" = "Drupal\node\NodeRenderController",
 *     "access" = "Drupal\node\NodeAccessController",
 *     "form" = {
 *       "default" = "Drupal\node\NodeFormController"
 *     },
 *     "translation" = "Drupal\node\NodeTranslationController"
 *   },
 *   base_table = "node",
 *   revision_table = "node_revision",
 *   uri_callback = "node_uri",
 *   fieldable = TRUE,
 *   translatable = TRUE,


 * Returns a list of supported entity types.
 * @return array
 *   An array of entity type names.
function language_entity_supported() {
  $supported = array();
  foreach (entity_get_info() as $entity_type => $info) {
    if (!empty($info['translatable'])) {
      $supported[$entity_type] = $entity_type;
  return $supported;


function translation_entity_preprocess_language_content_settings_table(&$variables) {
  module_load_include('inc', 'translation_entity', 'translation_entity.admin');

 * Stores entity translation settings.
 * @param array $settings
 *   An associative array of settings keyed by entity type and bundle. At bundle
 *   level the following keys are available:
 *   - translatable: The bundle translatability status, which is a bool.
 *   - settings: An array of language configuration settings as defined by
 *     language_save_default_configuration().
 *   - fields: An associative array with field names as keys and a boolean as
 *     value, indicating field translatability.
 *   - columns: An associative array of translation synchronization settings
 *     keyed by field names.
function translation_entity_save_settings($settings) {
  foreach ($settings as $entity_type => $entity_settings) {
    foreach ($entity_settings as $bundle => $bundle_settings) {
      // The 'translatable' value is set only if it is possible to enable.
      if (isset($bundle_settings['translatable'])) {
        // Store whether a bundle has translation enabled or not.
        translation_entity_set_config($entity_type, $bundle, 'enabled', $bundle_settings['translatable']);

(see #1977784: Content language settings configuration page needs to determine what entities and bundles to include also)

for example, function _translation_entity_form_language_content_settings_form_alter

Proposed resolution

Remaining tasks

Discuss if there is a need to make the UI more consistant, if so, open an issue.

User interface changes


API changes


Related Issues


YesCT’s picture

Title: Copy of Content language settings configuration page needs to determine what entities and bundles to include » translatable vs multilingual vs language-aware

in the code to know if something can have translation enabled, so that it can be translated by users in the ui,
check the entity info for the translatable annotation
if it has fields
[if it has fields that can have translation enabled] (I think we said all fields can be translated so we dont have to check if the field type is translatable)

In the UI, something is translatable (translatable checkbox checked) or not translatable (translation checkbox not checked).
There is also sometimes no choice to be translatable... this no choice is maybe.. not multilingual/language-aware? And there is where in the entity info annotation, translatable = TRUE is used to indicate that it should be able to chose translatable or not, *if* the other conditions for translatable are met like: fieldable and has fields.

language_entity_supported() used to check if it was fieldable. fieldable is not needed for language support but maybe we need a function for
translation_entity_supported() to check the entity info, if it has fields?

when properties are fields, there may not be any entity that does not have something that can be translated.. so we might not have to check for fields anymore.

YesCT’s picture

Title: translatable vs multilingual vs language-aware » translatable, translation enabled, multilingual, language-aware
YesCT’s picture

Issue summary: View changes

added related issues

YesCT’s picture

Issue summary: View changes

added mutlilingual and language aware.

YesCT’s picture

Issue summary: View changes

added some code examples. (might be better as a comment so as not to clutter the issue summary..)

YesCT’s picture

Issue summary: View changes

"this" referred to the other issue

Gábor Hojtsy’s picture

Component: translation_entity.module » content_translation.module
Gábor Hojtsy’s picture

Issue summary: View changes

added an example of the translatable setting used on bundles to mean translation support.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.