fix: #3637712 Use the page language for CKEditor 5 content in Layout Builder
Issue: https://www.drupal.org/i/3637712
Layout Builder block forms are admin routes. With the interface language following the admin language (English admin on an Arabic site), CKEditor 5 used the UI language for content, so Arabic was edited as lang="en" dir="ltr".
A new final class src/Hook/EditorLanguageHooks.php implements #[Hook('editor_js_settings_alter')] and sets editorSettings.language.content to the page's URL language on layout_builder.* routes, mapped through Drupal\ckeditor5\LanguageMapper, with a fallback to _ckeditor5_get_langcode_mapping() for Drupal 10. Drupal 10 does not discover hook classes, so it is registered in varbase_layout_builder.services.yml with explicit arguments (@?Drupal\ckeditor5\LanguageMapper optional). varbase_layout_builder_editor_js_settings_alter() stays in the .module file, marked #[LegacyHook], and delegates to the service: Drupal 11.1+ skips it and runs the OOP hook, Drupal 10 runs the procedural one. The toolbar stays in the admin language.
Tested on Drupal 11.4.12 (Varbase 9.2.x): invokeAllWith('editor_js_settings_alter') lists EditorLanguageHooks::editorJsSettingsAlter once, no procedural duplicate. The Arabic add-block form sends {ui: en, content: ar}, English sends {ui: en, content: en}.
Remaining tasks
- Pipeline 1044448 green. Locally phpcs passes; phpstan (91) and cspell (7) report the same counts as untouched 10.0.x, none in the changed files.
- Not runtime-tested on Drupal 10.6 (the
#[LegacyHook]path).
AI-Generated: Yes
Checkpoints:
- File an issue
- Addition/Change/Update/Fix
- Testing to ensure no regression
- Automated unit testing coverage
- Automated functional testing coverage
- UX/UI designer responsibilities
- Readability
- Accessibility
- Performance
- Security
- Developer Documentation
- User Guide Documentation
- Reviewed by human
- Code review by maintainers
- Full testing and approval
- Credit contributors
- Review with the product owner
- Release notes snippet
- Release