Hat tip to @jhodgdon for finding this.

Problem/Motivation

The Editor config entity cannot be translated because it does not have a dedicated edit form. Instead the editor settings are attached to the edit form of the TextFormat config entity.

Because editor settings do not have any translatable settings in core this is marked minor and also not tagged with sprint. However, because editor settings support third_party_settings contrib modules could add translatable values there and expect to be able to translate them with the Config Translation module. A use-case would be being able to edit button labels (or alt tags, or title tags).

Proposed resolution

Add the appropriate editor config object to the text format's config translation mapper.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Comments

tstoeckler created an issue. See original summary.

Wim Leers’s picture

Assigned: Unassigned » Gábor Hojtsy

I'm not quite sure what Add the appropriate editor config object to the text format's config translation mapper. means.

Also, there actually are translatable things even without third-party settings:

  1. Go to /admin/config/content/formats/manage/basic_html
  2. Drag the Styles dropdown from Available buttons to somewhere in Active toolbar
  3. Now a Styles dropdown vertical tab appears under CKEditor plugin settings. Enter something like blockquote.famous|Famous quote

Now Famous quote is a config value that you actually want to translate.

Assigning to @Gábor Hojtsy for feedback.

Gábor Hojtsy’s picture

#2546212: [PP-1] Entity view/form mode formatter/widget settings have no translation UI is a similar problem. Basically translation mappers in config translation map a set of config names to a route. So it can add a translate tab and several other routes to allow looking at translation status, translating the configs and deleting translations. So I think editor configs are edited on text format config pages, so you would need to alter the mapper for text formats to also have the editor entity. Again all the things that #2546212: [PP-1] Entity view/form mode formatter/widget settings have no translation UI is postponed on would help as well as the implementation proposed for #2546212: [PP-1] Entity view/form mode formatter/widget settings have no translation UI overall.

Gábor Hojtsy’s picture

Assigned: Gábor Hojtsy » Unassigned
tstoeckler’s picture

Title: Editor settings cannot be translated » [PP-1] Editor settings cannot be translated
Priority: Minor » Normal

Ahem, that makes this definitely not Minor. Not sure if it should be Major even, I'll let others decide that. Thanks for the info!

What I meant was the following:
The Configuration Translation module works in a way that can point it to a route and tell it what config objects to translate and then it adds new routes that live under /translate for the translation UI. We call these things "config mappers".

Benefitting from the generic integration we have for config entities, you can already translate text formats at e.g. /admin/config/content/formats/manage/basic_html/translate. Thus a config mapper already exists for text formats. Because Text Editor module enhances the text format UI and adds corresponding config objects, so it should also enhance the text format translation UI to add the respective editor.editor.* config object to the text format mapper.

Writing this, I realize this in fact needs #2577761: We need a way to dynamically alter the list of config names for config mappers in order to work. Once that is in, editor module could add an event subscriber which listens to the ConfigTranslation::POPULATE_MAPPER event and then does something like:

if (($mapper instanceof ConfigEntityMapper) && ($mapper->getId() === 'text_format')) {
  $text_format_id = $mapper->getEntity()->id();
  if ($editor = $this->editorStorage->load($text_format_id) {
    $mapper->addConfigName($editor->getConfigDependencyName());
  }
}

(or similar)

EDIT: Massive x-post!

tstoeckler’s picture

Wim Leers’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed

Updating status to reflect reality. Blocked on #2577761: We need a way to dynamically alter the list of config names for config mappers, hence marking as postponed. And since #2577761 was moved to 8.1, also moving this issue to 8.1.

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

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now 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.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.