I built the Language Install Audit module to find and measure fixing issues in how content and config gets created in the installation of core and Drupal CMS in particular. When installing Drupal core with German as an example, it is almost perfect. The "errors" noted are configuration that do not have translatable pieces. While this looks logical on the surface, it quickly falls apart :)
A great example is the two text editors that get created. One has 14 source strings and is German. The other has 0 source strings and is English. However on a German site English is not a known language. This is not a problem until the editor gets something that is translatable. Once it gets something that is translatable, which is easy to achieve on the UI, that is not possible to translate and the config translation UI produces an exception.
That the config as shipped did not contain translatable things do not mean it will not need to be translatable shortly after. Config has various dynamic parts, plugins, etc. Such as the CKEditor example shows.
This also potentially causes problems if any module wants to add 3rd party settings to the config, as the langcode of the config will be not known to the site and the 3rd party settings will not be possible translate even if they would be translatable.
Note: Language Install Audit module has been superseded by Language Audit, which has slightly different screenshots and is located in "Configuration > Region and language" instead of "Reports"
UI of config translation after the steps above (prior to the MR):
Language Install Audit for editor config after the above steps (prior to the MR):
Caveat: if you install a module after doing the above steps, it "fixes itself" because the config langcode update / translation update runs. However that should not be a suggested solution to install a random module to fix a configuration issue.
Due to 3rd party settings support config entities should always have a langcode even if they do not have translatable items at install time. That means config entities installed from extensions should always have a valid langcode and be in the site default langcode unless otherwise specified.
Language Install Audit output after the MR:
Reviews welcome!
None.
None.
None.
None.
Default configuration entities imported now always has a language code to support later changes to configuration especially third party settings. For existing sites this means configuration entities that were originally installed by extensions and that lack a language code in active storage will receive the site default language code on the next extension install even for configuration entities that had no translatable elements directly.
Show commandsStart 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:
changes, plain diff MR !16065
Comments
Comment #2
gábor hojtsyComment #4
gábor hojtsyCorrect the steps to install config translation BEFORE changing the editor, as doing it after will "fix" the config. Doing it in the other order results in the bugos config.
Comment #5
gábor hojtsyAdded an explicit question to the remaining steps and expanded release note snippet for current state.
Comment #6
gábor hojtsyComment #7
gábor hojtsyLanguage Install Audit is all green after this MR on core installing in German.
Comment #8
gábor hojtsyMore explicit description of screenshots.
Comment #9
gábor hojtsyLet's limit this to configuration entities as those can get third party settings. Other configuration theoretically can's get data from outside the module that manages them. At least limiting to configuration entities will limit the scope for now.
Comment #10
gábor hojtsyCreated a parent issue to collect related issues.
Comment #11
gábor hojtsyUpdated issue summary for new scope with configuration entities.
Comment #12
roderikTL/DR: reviewed + tested; next comment will contain some questions about context. This comment is just a log plus a question about Language Audit at the very bottom bullet.
Reviewed:
Reproduce STR to see if anything pops out:
BEFORE MR:
drush si --locale=dedrush en language_audit config_translation # important to do this before editingdrush cget editor.editor.full_htmlshows me the 14 strings at > plugins > ckeditor5_codeBlockdrush cget editor.editor.basic_htmldoes not have those yet.drush cget editor.editor.basic_htmlnow contains the 14 translatable strings.drush en ban # or any other moduledrush cget editor.editor.basic_htmlnow has "language: de", though the labels contain English text (notably: "Plain text", while editor.full_text has "Klartext") <<<<<AFTER MR:
drush cget editor.editor.basic_htmlis immediately 'de' and the reported issues in admin/config/regional/audit are gone. <<<<< fixed.drush cget editor.editor.basic_htmlagain shows the labelsSo, the error is gone. But, just noting some related things that I don't know about:
I see the called
LaunguageAuditController::getLocaleTranslatableDefaultConfig() -> $locale_config_manager->getTranslatableDefaultConfig()still returns 0. I don't know this code; my first guess would be it is the "Default" part, and Language Audit does not show the current translations? Is this... intended?Comment #13
roderikThis is a 'cautious review', because I understand what's going on in this MR and why - but likely not the wider context of config translation code.
So... I have one main question before RTBC:
This solves things for config entities. Can we fix the equivalent situation for simple config, which I encountered for samlauth in #3611776: samlauth.authentication config object must specify a language code?
Either in this issue (I will leave an MR comment with some context)...
Or in a followup? In which case... do I need to create a separate followup, or is work going to continue in #3337864: Introduce a dedicated "Configuration default language" different from "Site default language", which would also solve that? I'm not sure of its status. I'll just note it looks like it will solve my #3611776 issue by forcing language code 'lazily', at save time whenever a translatable value is first introduced, while this MR explicitly chooses to solve the equivalent thing (for config entities) at install time.
Or: is any module just required to prevent this situation for simple config? (I imagine not.)
Comment #14
roderikOK. I'm going to set this RTBC, because
---
I do not know for 100% sure, whether the changes introduced here, influence #3337864. My current guess is "no", because
My previous guess was that #3337864 supersedes this issue, because it does things on Config::save() which means this wouldn't be needed anymore. (@alexpott also suggests something similar on Slack. Then again... wouldn't that suggest that code in LocaleConfigManager::updateDefaultConfigLangcodes() is going to be not needed anymore?)
But I think that's for #3337864 to figure out. It has current activity by people more knowledgeable than me. This is reviewed/tested, so I'm going to leave it to the others to merge or close-as-duplicate.
Comment #15
roderikComment #16
alexpottThis needs an update path but I'm going to defer that until we solve #3337864: Introduce a dedicated "Configuration default language" different from "Site default language" as that needs an upgrade path too. The other thing that should be investigated is that this bug suggests entities are being created without \Drupal\Core\Config\Entity\ConfigEntityStorage::doCreate() being called - which sure guarantee a langcode is set on entities as we need to work out why that is.
Committed and pushed 73847ce09f3 to main and f84b6e6b030 to 11.x and a5d3407d021 to 11.4.x. Thanks!
Comment #21
alexpottOkay I've just merged this issue with #3337864: Introduce a dedicated "Configuration default language" different from "Site default language" and re-run the core/tests/Drupal/FunctionalTests/Installer/InstallerTranslationMultipleLanguageForeignTest.php test - it passed - which surprised me. So I then went and re-ran the test without the fix and it also passed. So I don't think this has solved the issue completely but I think it is still worth doing so leaving in.