Changelog¶

All changes with their purpose, newest first.

Unreleased – move to drupal.org¶

New link preview for the documentation: it names the installation and all 22 site templates, next to the German template selection of the installer.
Gallery: the documentation of Default Content Locale Extended has a gallery page that opens as a slideshow of the front pages of all 22 templates in German (arrow keys, swipe, Escape; ?template=<key> starts at a template). It has its own link preview, a collage of all templates. Without JavaScript it stays a normal gallery.
Provus EDU: the Google Translate switch in the top bar shows the language of the page, "Deutsch", instead of "Englisch".
The Rightup, Educare, Horizon Aid and Varbase: "By" before the author name is translated ("Von Alex Suskind"); in the byline component it stands on a line of its own, which the theme fix did not cover.
New screenshots: the template selection of the installer (light and dark) and, in the documentation of Default Content Locale Extended, the front pages of all free templates after an installation through the web installer. tests/web-installer/install.py takes the installer screenshots when INSTALLER_SHOTS is set.
Running installer_de_patch.sh again on an existing project now brings in the current fixes. The patch scripts insert each fix only once, so a project patched by an older version kept the older fixes. The script now reinstalls the Drupal CMS installer and Canvas unchanged first (composer reinstall) and then patches them like a fresh project. Fresh projects are not affected.
Dates in the themes of the templates follow the site language: "1. Okt 2026" instead of "Oct 1, 2026". Ten themes formatted dates with Twig's date filter, which knows no translation; the installer switches them to Drupal's date formatter with a translatable pattern (report 58).
Varbase templates show their images again: they switch the image toolkit to ImageMagick even where it is not installed, so no image style could be generated and content images stayed empty. The installer switches back to GD if ImageMagick is missing (report 49). The GitLab job now also fails on logged image errors. Tested with Varbase Starter: image styles are generated, no image errors.
Provus EDU can be installed: line breaks in a prompt of the AI SEO module made one of its configuration files unreadable. The installer indents the affected lines after the download, the text stays the same (report 55). Tested through the web installer: 113 pages, no server errors.
New GitLab job web-installer: installs every free template through the web installer in German, one job per template, and checks the pages afterwards (tests/web-installer/). It runs in scheduled pipelines or when started by hand, see How it works.
The template selection also shows the description of the Nuxt Starter recipe in German.
Multilingual site templates such as Dashi (content in English and Spanish) are set up in German if Default Content Locale Extended ships a German translation of the template; before, the Drupal CMS installer set the site up in English (report 42). English and Spanish are kept. Tested with Dashi: front page, recipes, articles and Canvas pages in German, /en/ and /es/ unchanged.
Web installer: all free templates have now also been tested through install.php, not only with Drush. Dashi (500 on every page), Varbase and The Rightup (installation stopped) showed references to Canvas components that only go missing with the web installer; dcle now handles them (report 54). Large templates also need more PHP memory, see Installation. Provus EDU fails on a bug in the AI SEO module (report 55), Nuxt Starter still on Composer (report 13).
Horizon Aid: the theme fix also covers the Horizon Aid theme, and the template selection shows the description of its recipe in German. All 23 free templates of the installer are now translated. Tested: all pages in German. The installation first failed because Canvas gives a views block a new version on a German site; the module now handles that (report 54).
Educare: the theme fix also covers the Educare theme, another copy of Vartheme BS5; the template selection shows the description of the Educare recipe in German. Tested: all pages in German, apart from texts the template copies from other universities (report 52).
The Rightup: the same fix applies to its theme, a copy of Vartheme BS5; the template selection shows the description of the Rightup recipe in German. Tested: all pages in German.
Varbase: "By", the slider buttons and two navigation labels of Vartheme BS5 become translatable (report 50), and the template selection shows the description of the Varbase recipe in German. Tested: all pages in German.
Goodwell: about 20 hard-coded English texts of the Goodwell theme (premium calculator, testimonial slider, screen reader labels) become translatable (report 46). The calculator's " / month" comes from JavaScript; the template passes the translation along as a data attribute, because the front page loads no Drupal.t() for guests. The template selection also shows the description of the Goodwell recipe in German. Tested: all pages in German, the calculator shows "/ Monat".
Hourglass Corporate: about 40 hard-coded English texts of the Hourglass theme ("Published", "Share", "Read More", search, screen reader labels) become translatable (report 44). The theme fix now takes a list of texts per theme. Tested: all pages in German, no hard-coded text left in the theme's templates.
German descriptions for the new templates in the template selection: Dashi, Hourglass Corporate, Goodwell, Varbase, The Rightup, Educare and Horizon Aid.
The installer is now the drupal.org project Drupal CMS German Installer (dcgi). Development happens in the 1.0.x branch on git.drupalcode.org.
installer_de_patch.sh now downloads the installer from https://git.drupalcode.org/project/dcgi.git, branch 1.0.x.
The step before the content import installs Default Content Locale Extended (dcle, with dcle_canvas) if it is in the project, otherwise the original module as before. Previously templates stayed English with dcle, because the step only knew the original's name.
New documentation built with Zensical, in German and English, in the style of the Default Content Locale Extended documentation. README and CHANGELOG point to it.
The installer now uses Default Content Locale Extended (drupal/dcle:1.0.x-dev@dev) instead of the original module. In older projects installer_de_patch.sh replaces the original. The fix scripts/default-content-locale-fix.php is gone, dcle fixes those bugs itself. Tested: fresh project via the script, Haven in German, 285 of 285 texts, no English text blocks.
The Twig restriction only applies to Drupal core before 11.4.8, which works with Twig 3.30 again.

Unreleased – more templates in German¶

Tested with Drupal CMS 2.2 and the templates Haven, Byte, Everbright, Forma, Mercury Demo and Convivial Gov, each installed in German. The translations themselves come from the module dcle (Default Content Locale Extended), the fork of default_content_locale (see there).

"Follow us on …" and the video notice are translated (`scripts/i18n-extras-fix.php`)¶

Problem: Mercury and all site template themes generated from it (Haven, Byte, Everbright, Forma, …) hard-code two strings without |t: - the screen reader label of the social media icons (menu--social.html.twig). It does not even contain the network name, because item.title has already been replaced by the icon, so screen readers only hear "Follow us on". - the notice in the video component ("Your browser does not support the video tag.").

Solution: Before the template's content is imported, these spots are replaced by translatable strings, using the network name from the menu link. Result: "Folgen Sie uns auf Instagram". This is a workaround until the themes are fixed.

Templates that set English as the site language (Convivial Gov)¶

Problem: Convivial Gov sets system.site: default_langcode: en in its recipe. On a German installation the site was therefore temporarily English while the content was imported. As a result, Default Content Locale was not enabled, and all content was saved as English. At the end the installer removes English, which left the content in a language the site does not have.

Solution: Before the content is imported, the chosen language is created and set as the default. The installer does exactly this at the end anyway (drupal_cms_installer_add_chosen_language()), just earlier now. Not when English is kept.

Unique batch steps, for real¶

The inserted steps used to be told apart by their position in the list. The installer, however, compares against all steps in the batch, including those of earlier recipes, so a step could be dropped as a duplicate. They now carry the path of their recipe.

Open¶

~~The package still requires drupal/default_content_locale.~~ Done: the installer now uses dcle (see above).
When testing: reloading the site in the browser during the installation can write an unfinished state to the cache (e.g. a 500 error on Convivial Gov). drush cr fixes that.

2.2.0 – Adaptation to Drupal CMS 2.2¶

Tested with Drupal CMS 2.2.0 (drupal/drupal_cms_installer 2.2.0, Drupal core 11.4.7, PHP 8.5). Drupal CMS 2.1.x is still supported.

The whole flow was tested: a fresh project via installer_de_patch.sh, then every step of the web installer live in the browser in German – language selection, database, site name, template selection including the license dialog, user account, installation – with the Haven and Byte templates, both downloaded via Composer. Also tested: patching an existing project, cleaning up after the installation, and reinstalling after drush sql:drop.

The changes are grouped by purpose: what broke or was missing, why, and what the change does about it.

1. The installer has to work with Drupal CMS 2.2 at all¶

1.1 The i18n_extras recipe is applied again¶

Problem: Drupal CMS 2.2 removed the RecipeHandler class. So far, scripts/i18n-extras-fix.php hooked into its enqueue() call in SiteTemplateForm. That spot no longer exists. The script only printed a warning, and the add-on modules (pb_localizer, yoast_seo_i18n, default_content_locale, Gin dark mode) were silently no longer installed.

Solution: In 2.2, recipes are only turned into batch operations inside drupal_cms_installer.profile. There are two paths: templates that already exist locally run in the same batch, templates downloaded via Composer run in a later batch. The script now appends i18n_extras right after the template on both paths.

Side effect: In 2.1, i18n_extras often ran before the template for downloaded templates such as "convene". Now the order is guaranteed in both cases. The old approach remains as a fallback for 2.1.x.

1.2 The installer starts again (missing icons)¶

Problem: The new language switcher in 2.2 is a dialog. It includes its icons via active_theme_path(), i.e. from the currently active theme – which is our DE theme. check.svg was missing there, and the installer would have failed with a Twig error.

Solution: The icons in images/ now match 2.2. check.svg and search.svg were added; chevron-down, spinner, translate and x-circle were updated. With the old x-circle.svg, the close button would also have been white on white.

1.3 Twig 3.30 breaks every fresh installation (`installer_de_patch.sh`)¶

Problem: Twig 3.30.0 (released 2026-09-25) now calls the escaper directly. Drupal core 11.4, however, redirects the escape filter to a function with a different signature. The very first installer page fails with: EscaperRuntime::escape(): Argument #4 ($autoescape) must be of type bool, null given. Because composer install without a lock file always pulls the latest version, this affects every fresh installation – even without this package.

Solution: Only if Twig 3.30.x is installed does the script restrict Twig via composer require "twig/twig:>=3.28 <3.30". Once Drupal core fixes this, remove the restriction with composer remove twig/twig.

2. Cleanup and reinstallation must not break anything¶

2.1 Reinstalling after cleanup¶

Problem: The second script run after installation deletes the DE theme. The patch in drupal_cms_installer.info.yml (theme: drupal_cms_installer_de), however, was left in place. Every later reinstallation, for example after drush sql:drop, then failed with Call to a member function getPathname() on null in InstallerKernel->getBaseThemes().

Solution: Cleanup now resets that line to drupal_cms_installer_theme.

2.2 Reliable "already installed?" detection¶

Problem: The script treated a site as installed as soon as settings.php existed. After drush sql:drop the file is still there, although the database is empty. Running the script again would then only have cleaned up instead of wiring in the theme.

Solution: The check now uses drush status (did the bootstrap succeed?). Only if Drush is missing does the presence of settings.php still count.

3. Everything you see in the installer is German¶

3.1 New UI strings in 2.2¶

Background: Since 2.2, the installer itself downloads an official German translation from localize.drupal.org. It is incomplete, though. Our JS translations (js/installer-translations.js) now only cover what is missing or wrong there: - the new language dialog ("Install your site in a different language", search field, close button, "Select … and close dialog"). The script now also translates attributes such as aria-label, placeholder and title, so screen readers read German as well; - the template descriptions, "Learn more" and "License key". These strings come from the template list and cannot be translated officially at all; - the new finishing page ("Your site is almost ready"); - corrections to official or core translations: "Frei" → "Kostenlos", "Schluss machen" → "Abschluss", "MySQL, MariaDB, oder equivalent" → "MySQL, MariaDB oder kompatibel"; - the default value "Meine Drupal CMS Seite" → "Meine Drupal-CMS-Website", matching the heading, which says "Website". It is only replaced as long as the user has not changed it; - fixed the typo "Lizenztschlüssel".

3.2 Status messages during installation (`js/progress-override.js`)¶

Problem: In the first half of the installation, the progress bar showed English messages such as "Installed 20 modules: …", "Completed 3 of 22." and "Installed Haven theme.". The German core translations are only imported at the very end, and some messages have no translation at all.

Solution: The messages are translated in the browser before they are displayed. This uses patterns that leave placeholders such as module and recipe names untouched.

3.3 Detecting the right language (`js/langcode.js`, new)¶

Problem: In 2.2, the installer can switch the langcode parameter to the template's default language after the template is chosen, while it keeps talking to the user in the chosen language. The translations must not stop working then. Conversely, a language from an earlier installation in the same browser tab must not "stick".

Solution: In the early installer, the active language is read directly from the language switcher (the entry marked is-selected) and remembered. After that, the remembered language is used. Both JS files use this shared function.

4. Dark mode matches the new elements (`css/dark-mode.css`)¶

Problem: The previous styles targeted the old <select> in the header, which no longer exists. The new elements use light colour tones and would have been hard to read on navy.

Solution: New dark-mode styles for - the "change language" button, the dialog, the language list (hover and selection) and the loading overlay; - the magnifier icon in the search field: a background image with a hard-coded dark grey, so a light variant is used as a data URI; - the license key dialog of premium templates: previously a black background with a light blue backdrop, now navy; - the spinner on the new finishing page.

5. Template content is German right away (Default Content Locale)¶

Goal: After installing a template such as Haven, the content should be German too, not just the interface. The drupal/default_content_locale module ships translations for this (translations/haven.de.po) and applies them while the content is imported.

Four steps were needed to make this actually work:

5.1 Correct Composer integration (`installer_de_patch.sh`)¶

The module only exists as a dev version. So far, the script lowered the minimum-stability of the whole project to dev for it. That could have let Composer pull dev versions of other packages during later updates as well. Now the dev allowance applies to this one package only: drupal/default_content_locale:1.x-dev@dev. Tested, including with minimum-stability: stable.

5.2 The right moment (`scripts/i18n-extras-fix.php`)¶

Problem: The module only works if it is installed before the content is imported. It hooks into PreEntityImportEvent, and it imports its .po files in hook_install(). So far it was installed via the i18n_extras recipe, which deliberately runs after the template. It came too late, and Haven stayed English.

Solution: Right before each content import of the template, a step is inserted that installs default_content_locale. As soon as Canvas has been enabled by the template, default_content_locale_canvas follows too, because Haven's pages are Canvas pages. This works for local templates and for templates downloaded via Composer.

5.3 Bugs in the module (`scripts/default-content-locale-fix.php`, new)¶

Problem A: Installation failed with Column 'status' cannot be null. The module creates the German translation with the translated text fields only, and required fields such as status are missing.

Problem B: During installation, English is still the default language; core only removes it at the end. The content was therefore created in English and got German as a translation. After the switch, an orphaned English version remained, and content lists showed every entry twice.

Solution: If the target language is the installation language (config_language_lock), the English texts are replaced directly. Every piece of content then has exactly one German version. Only for additional languages is a translation still created, now with all required fields.

This is a patch to third-party code. It looks for one specific line of code and does nothing if that line no longer exists, for example because the module has been fixed. It should be reported to the module.

5.4 The front page no longer returns 404 (URL aliases)¶

Problem: Haven and Byte ship their URL aliases (e.g. /home for the front page) with a hard-coded langcode: en. On a German-only site they never match, and the front page returned 404. This happens even without this package.

Solution: After each content import, and once more at the end, English aliases are moved to the installation language. This only happens if English is not kept.

Technical detail: unique batch steps¶

The Drupal CMS installer discards identical batch operations ("Only do each recipe's batch operations once"). The inserted steps therefore carry a unique argument. Without it they would run only once, and corrections at the end would silently be skipped.

Result with Haven: Pages ("Startseite", "Über uns", "Führung"), posts ("Was uns die Riffe erzählen") and terms ("Klimawandel") are German, each with exactly one version. The front page works.

6. Other changes¶

installer_de_patch.sh: the theme source can be overridden for testing: INSTALLER_DE_REPO=… INSTALLER_DE_BRANCH=…. The default remains the master branch on GitHub.
composer.json: version 2.1.0 → 2.2.0.
README: compatibility section for 2.2, Twig note, Default Content Locale.

Known open issues (cannot be solved in this package)¶

Haven content: Two sentences on the front page remain English ("The connection between disappearing glaciers…", "Every small action counts…"). They are missing from the module's haven.de.po.
Official installer translation: The language dialog strings are missing on localize.drupal.org. Until then, our JS covers them.
Dashboard after installation: "Recent pages", "Recent content", "See all pages/content" and "Help" are English, and there is the typo "Weiter Veranstaltungen anzeigen" (should be "Weitere").
Upstream bugs unrelated to translation:
The help texts under "Advanced options" on the database page run underneath the artwork.
If the hidden license field holds an invalid value, clicking "Next" does nothing, without any feedback.
The batch pages have no tab title; it only says "| Drupal CMS".
Patches to third-party code: composer update can overwrite the installer and default_content_locale. Run installer_de_patch.sh again in that case; every patch detects whether it has already been applied.