Problem/Motivation
At the moment config object require a langcode key when the config is has a translatable value and this is dynamically determined by Locale using schema:
config_object:
type: mapping
mapping:
_core:
# This only exists for merging configuration; it's not required.
requiredKey: false
type: _core_config_info
langcode:
requiredKey: false
type: langcode
constraints:
# The `langcode` key:
# - MUST be specified when there are translatable values
# - MUST NOT be specified when there are no translatable values.
# Translatable values are specified for this config schema type (a subtype of `type: config_object`) if the
# `translatable` flag is present and set to `true` for *any* element in that config schema type.
LangcodeRequiredIfTranslatableValues: ~
and \Drupal\locale\LocaleConfigManager::getTranslatableData()
This is unreliable as config entities may have third party settings or plugins that add translatable keys and we'll only know that they are translatable if there is a value. This situation is also possible with simple config which has a translatable value that is not required.
This issue blocks #3337864: Introduce a dedicated "Configuration default language" different from "Site default language"
Steps to reproduce
Proposed resolution
- Add
\Drupal\Core\Config\TypedConfigManager::hasTranslatableValues()which will return: TRUEfor all config entities - these always support third party settings so we just do know.- Will return TRUE if the simple config has updated it's schema to require the langcode
- Will use the complete schema and not values if the schema has
requiredKey: false - The LangcodeRequiredIfTranslatableValues will use the same logic.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3616515
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
alexpottI discussed this issue with @gábor hojtsy and we came to the conclusion that static analysis of the schema was not going to cut it because modules can add to schema when installed that will change a schema from untranslatable to translatable. And therefore we'd need a process to ensure all configs got a langcode when this occurs. This will mean that configs will get a langcode even when they have no translatable values - imagine the situation where a module adds a new plugin that can be configured in a simple config but none of the existing plugin implementations have a translatable value.
Therefore we need go back to #3337864: Introduce a dedicated "Configuration default language" different from "Site default language" and work out how to implement using the current value based determination of translatability.