Config Translation introduces the concept of translation mappers so that arbitrary config objects can be translated with config translation forms. We even have a ConfigMapperInterface::addConfigName() method so that contributed modules can control add their config objects to translation forms.

Sadly, though, contributed modules never actually get a chance to call that method at an appropriate time, so that de facto it's not possible to enhance config translation forms.

This came up in #2546212: [PP-1] Entity view/form mode formatter/widget settings have no translation UI where Field UI module wants to alter the config translation mappers of various other modules. This is a Config Translation critical, but that probably still just makes it normal in the core queue.

Proposed resolution

Move the actual form building of the config translation form into #process, so that hook_form_alter() implementations have a chance to add config names.

Remaining tasks

User interface changes


API changes


Data model changes


#2 2571407-1-ct-alter.patch3.33 KBtstoeckler
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,555 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


tstoeckler created an issue. See original summary.

tstoeckler’s picture

Status: Active » Needs review
Related issues: +#2546212: [PP-1] Entity view/form mode formatter/widget settings have no translation UI
3.33 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,555 pass(es). View

Here we go.

Gábor Hojtsy’s picture

The idea is you would do the altering of mappers in hook_config_translation_info() and/or hook_config_translation_info_alter() not through a form alter. Why do we need this?

Gábor Hojtsy’s picture

* Alter existing translation tabs for translation of configuration.
* This hook is useful to extend existing configuration mappers with new
* configuration names, for example when altering existing forms with new
* settings stored elsewhere. This allows the translation experience to also
* reflect the compound form element in one screen.
* @param array $info
* An associative array of discovered configuration mappers. Use an entity
* name for the key (for entity mapping) or a unique string for configuration
* name list mapping. The values of the associative array are arrays
* themselves in the same structure as the *.config_translation.yml files.
* @see hook_translation_info()
* @see \Drupal\config_translation\ConfigMapperManagerInterface
function hook_config_translation_info_alter(&$info) {
// Add additional site settings to the site information screen, so it shows
// up on the translation screen. (Form alter in the elements whose values are
// stored in this config file using regular form altering on the original
// configuration form.)
$info['system.site_information_settings']['names'][] = '';

tstoeckler’s picture

Status: Needs review » Closed (won't fix)
Related issues: +#2577761: We need a way to dynamically alter the list of config names for config mappers

Thanks for the info. Yes, this is in fact not needed. The fun stuff is now happening at #2577761: We need a way to dynamically alter the list of config names for config mappers.

Gábor Hojtsy’s picture

Issue tags: -sprint

Removing from sprint then.