3

I have written a custom module providing two custom config entities holding data, that is not language-specific. But I can't seem to find a way to tell Drupal, that there is no need to "translate" these entities - in fact, I get this action offered on every entity listing.

Even all core entities I found so far implement translation, but some provide their own translation handler. (Is this maybe a way to do it? Implementing a custom translation handler that tells Drupal not to translate anything? But how?)

Is someone out there who can point me in the right direction please?

My actual annotation look like this (please notice the "translatable" option, which is not working):

@ConfigEntityType(
  id = "ad_tag",
  label = @Translation("Advertisement tag"),
  module = "field_vimeo",
  config_prefix = "field_vimeo.ad_tag",
  admin_permission = "administer site configuration",
  translatable = FALSE,
  handlers = {
    "storage" = "Drupal\field_vimeo\AdTagStorage",
    "list_builder" = "Drupal\field_vimeo\AdTagListBuilder",
    "form" = {
      "default" = "Drupal\field_vimeo\Form\AdTagForm",
      "delete" = "Drupal\field_vimeo\Form\AdTagDeleteForm"
    }
  },
  links = {
    "edit-form" = "/admin/structure/field_vimeo/ad_tags/manage/{ad_tag}",
    "delete-form" = "/admin/structure/field_vimeo/ad_tags/manage/{ad_tag}/delete"
  },
  entity_keys = {
    "id" = "id",
    "type" = "type",
    "label" = "label"
  },
  config_export = {
    "id" = "id",
    "type" = "type",
    "label" = "label",
    "data" = "data"
  }
)
  • I deleted that answer about translatable, seems it was based on old code. Doesn't look like there's currently a way to mark an entity type as monolingual but I might be wrong – Clive Dec 14 '15 at 10:58
  • The translatable switch is a correct one. See \Drupal\Core\Entity\EntityType::$translatable but also in your base field definitions you should omit setTranslatable method or declare setTranslatable(FALSE). Whether the entity definition setting collides with field settings I am not sure but these are the official "methods" in regard to making entities translatable. – user21641 Dec 14 '15 at 11:20
2

Translatability for config and content entities is different. Translation handler is a content entity thing. Storage for translations needs to be explicitly enabled by adding a data table.

For config entities, it's different. Translatability works automatically there through config overrides. There's nothing that you need to do to opt-in to being translatable, but you also can't prevent it. What you can is control which properties are translatable through the config schema. Like the label,which is, technically, a translatable, user-provided string.

If you don't need it translated, just don't create any translations for it or if you don't need any configuration translations, don't enable the config translation module.

  • There might be config entities, which contain language-specific values - which is why the config translation module has to be turned on. On the other hand, there might be config entities without any language-specific content (and even with an untranslatable label, too. Just think of names!). And then there are editorial employees of a customer that get a "translate" action offered on untranslatable config entities (and, as they are unaware of potential side effects their actions may have) actually use this "translation possibility. So I'm afraid your approach is just insufficient... – user1172447 Dec 15 '15 at 8:53
  • It's not "my approach". It's how it is. That links is added in config_translation_entity_operation(), you can try to implement hook_entity_operation_alter() and remove it. Or you can try to alter the entity type and remove the config-translation-overview link template. Anything else is a feature request against core. – Berdir Dec 15 '15 at 9:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.