Is language enough? Contextual configuration in Drupal

Drupal 8 gives us powerful support for interface and content translation. It also provides a mechanism for configuration overrides that work.

That's great news for Drupal site builders. But is it enough?

• Config Translation shows us that schema mapping is critical to build a UI for config overrides. Building the form requires the schema.
• Schema has some of the required metadata for building this form. The rest (access control, for instance) is stored in the route.
• Config Translation handles config entities, config objects, and field config. The required metadata for routes and access control (used to build the list of translatable strings) can be derived for config entities and field config, but not for config objects.
• Config objects, therefore, have their own special mappers (*.config_translation.yml), whose sole purpose is to map Routes (and therefore paths and access control) to Schemas, which allows the Config Translation UI to work.
• The support for config objects in those *.config_translation.yml files is limited to string data types, because that's what Config Translation cares about.

Suppose, however, the following use-case for a site:

• When Hungarian is the default language context, timezone should be CEST (UTC + 1:00); when Japanese is the default language context, timezone should be JT (UTC + 9:00).

Right now, you cannot discover the proper data to use to recreate:

• A route to the default configuration form for settings.date.
• The schema used by that form.
• Access control rules that should be applied to that form.
• A way to discover config objects that are not strings (like timezone).

As it stands now:

• Core works fine if you want to manually edit and load configuration files. The override system handles that cleanly.
• If you want to build a UI for contextual variables, core Config Translation is not sufficient as a model. By design, it only cares about strings, which means it ignores many of the variables that we would want to override per context.
• There are places in core -- specifically entity link registration -- where hardcoded exceptions are made for Config Translation. These instances should, ideally, be identified and abstracted, so that Config extension via context is more general and pluggable. (This is, however, a separate issue.)

This topic is a rather advanced and perhaps rare use-case, but in previous Drupal versions, we have had numerous concepts of global or local context (groups, urls, taxonomy terms) that might benefit from configuration overrides.

So the questions posed by this session are:

• Do we care enough about contextual configuration to support it completely?
• What changes would that require in core?
• What changes would that require in Config Translation?