## Problem Site templates can ship demo content in more than one language, for example English content with Spanish translations. The Drupal CMS installer lets people pick any language **before** they choose a template. Today that combination breaks Canvas if the chosen language is not one the template ships content in. Core's default content importer decides the language of each entity while importing it (`\Drupal\Core\DefaultContent\Importer::verifyNormalizedLanguage()`). During installation. When the content's language differs from the site default language, it takes the first shipped translation with language the site already knows and makes that the entity's default language. If there is none, it relabels the default version of the default content as the site default language. Translations in languages the site does not know are skipped. Later, core's translation import task makes the chosen language the site default and deletes English, unless the install profile asks to keep it. Which languages the site "knows" at that point is key. While the template is applied, the only language that exists without a `language.entity.*` config entity is the site default language. So a template that ships translations **has to ship the language entities for them**, otherwise its translations are never imported in any install. Core's own multilingual demo profile ships `language.entity.es.yml` for that reason. For a template that ships English content with Spanish translations this means these scenarios could come up based on language chosen in the installer: - **English chosen:** works fine. - **Spanish chosen:** the Spanish translation becomes the content's language, but **the English values are thrown away** rather than kept as a translation. On top of that, if the template ships an English language entity, **English is deleted from the site at the end**, because the Drupal CMS installer never asks core to keep it. - **Any other language chosen, say Hungarian:** with the Spanish language entity shipped, the importer picks Spanish as the content's language, **throws the English values away** and imports nothing in Hungarian. On a site with default language Hungarian this breaks Canvas entirely as the config/site default configured is not the same as the content language! If we would not ship the Spanish entity, the English content would be imported "as Hungarian", and the Spanish translations would be dropped. At least Canvas would work in this case, but this would be defeating the purpose of the site template. A site template cannot fix this by itself. Several things decide the chosen language before a template gets a say: core writes it into `system.site` when it installs the System module and sets the runtime default language from the `langcode` URL parameter on every installer request, which drives the content importer; the installer locks the configuration language to the chosen language before any recipe runs; and core's translation task rewrites the site default language after the template recipe has already been applied. If we would add a `system.site` updater config action in the template, the result of that would be later overwritten. ## Proposed resolution A We could change the order of screens in the installer, move up site template selection, then merge the site name, language and user screens, making the user flow faster too. In this case the language selection could be offered based on parameters the site template can specify, so it could limit or remove the language selector or provide an explanation what is the chosen language used for. The tradeoff of this solution is that the template selector would always be in English. The benefit is we could have one less installer screens in all scenarios and also the language selection could be affected by site templates. ## Proposed resolution B Keep the installer flow as-is. Let a site template declare which languages it ships its content in, and make the installer respond to that mid-flow. 1. Let a template declare its content languages in `recipe.yml`: ```yaml extra: drupal_cms_installer: languages: default: en available: - en - es ``` 2. When the chosen language is one of the available languages, the site is installed in that language as today. If the template ships English content, the installer must ask core to keep English (`keep_english`). While the template is applied, an event subscriber in the installer profile keeps the original values as a translation when core swaps content into the chosen language, so nothing shipped is lost. Core should do this, so this is a polyfill, issue to be opened if we agree. 3. When the chosen language is not one of the shipped ones, the installer sets the site default language to the template's default language before the recipes run, so the content is imported exactly as shipped. The installer keeps using the user chosen language for its own screens. After the template is applied, the user chosen language is added to the site. Language and Locale are installed along with the profile, so the existing translation tasks import interface translations for every language on the site, including the chosen language. The configuration language lock is pointed at the site default language (which is the template's default language), but the administrator account gets the user chosen language as its preferred language. 4. Templates that declare nothing behave exactly as today. A template has to ship a language entity for every language it declares as available, including the intended default one. The configuration language lock keeps following the site default language. The template's language plan is maintained in a `LanguagePlan` value object throughout the installer. The installer re-applies it on every request, because core derives the default language from the URL parameter each time. ## User interface changes None. A multilingual site template would not be broken though :smile: ## API changes - New optional `languages` key under `extra.drupal_cms_installer` in site template recipes, with `default` and `available`. - New internal `LanguagePlan` value object in the installer, and a `languages` property on `SiteTemplate`. ## Data model changes None. ## LLM disclosure The analysis of the installer and core code, the implementation and a previous version of this write-up were drafted with an LLM. I reviewed and edited them and stand by the content.