Need a reliable way to determine if a specific bundle for an entity type is translatable

Created on 20 February 2012, about 13 years ago
Updated 4 May 2025, 6 days ago

Problem/Motivation

  1. We need a reliable way to tell whether an entity type can be multilingual: a non-multilingual entity will never have multilingual support. For instance its SQL storage controller won't create a data table. This will be useful for ET to determine which bundles can be enabled for translation (see the next item). We could even provide simplified controllers based on this.
  2. We need a reliable way to tell whether a bundle is translatable or not.
  3. We should not require ET to be enabled to retrieve the information above.
  4. We should avoid calling entity_get_bundles() from translation_entity_entity_info_alter().

Proposed resolution

  • Add a 'translatable' boolean entity key.
  • Add a 'translatable' entity key to the bundle info and add also a helper method EntityInterface::isTranslatable() so that the key does not need to be actually populated.
  • Stop calling entity_get_bundles() while altering the entity info: ET should create the translation overview route for each translatable entity type, no matter if it has any bundle enabled for translation yet. The tab visibility should be determined by access control as usual.

Remaining tasks

  • Determine a strategy to backport this
  • Write a patch
  • Review, test, RTBC

User interface changes

None

API changes

  • The field translation handler concept has been removed in favor of a 'translatable' flag in the entity info.
  • A new 'translatable' flag has been added to the bundle info, determining whether the bundle is enabled for translation.

Follow-ups

#1945348: Call decorated storage methods in ViewsUI explicitly β†’

Original report by Dave Reid

For example, if I enable content translation (either via translation.module or a contrib module) for article node types but not page nodes, those modules should be altering hook_entity_info() for $info['node']['bundles']['article'] to indicate that translating is enabled.

Something like:

/**
 * Implements hook_entity_info_alter().
 */
function translation_entity_info_alter(&$info) {
  foreach ($info['node']['bundles'] as $type => &$bundle) {
    if (translation_supported_type($type)) {
      // Mark that translation.module is providing localization for this content type.
      $bundle['translation']['translation'] = TRUE;
    }
  }
}

Would also be nice to have a isTranslatable() method in the default Entity class that we can call as well (and an entity_is_translatable($entity_type, $entity) API addition for D7).

πŸ“Œ Task
Status

Fixed

Version

8.0 ⚰️

Component

entity system

Created by

πŸ‡ΊπŸ‡ΈUnited States dave reid Nebraska USA

Live updates comments and jobs are added and updated live.
  • API addition

    Enhances an existing API or introduces a new subsystem. Depending on the size and impact, possibly backportable to earlier major versions.

  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024