Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Unfortunately, we identified another issue with #3590050: Deprecate and replace locale_status related functions, existing sites have stored stdClass objects but we must now return LocaleTranslationSource
Steps to reproduce
Install in a multilingual site on 11.3, ensure you checked for translations at least once. Then update to 11.4
Proposed resolution
I think the easiest option is to just call \Drupal\locale\LocaleSource::clearSources() in a post update, so that the source information is rebuilt. This is non-persistent data, that's why that API exists, it's called automatically on the report page if the current data is old enough and some other cases too.
The alternative would be to convert from stdClass to LocaleTranslationSource but for all locale projects with a new version, we need to recalculate the information anyway.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3601433
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:
- 3601433-typeerror-localesourceloadsource-return
changes, plain diff MR !16086
Comments
Comment #3
berdirCreated a merge request. Our filled database dump for 11.4 doesn't include locale source information, so to reproduce this problem in an update test, we'd need to manually create the expected data structures to be able to have a failing test. I hope we can skip that considering the code is pretty trivial and easy enough to test manually. Maybe a follow-up to improve test coverage around that?
While testing this with drush locale:check and drush locale:update, I noticed another issue, namely that \Drush\Commands\core\LocaleCommands::update() does in fact rely on locale_translation_get_status() loading the locale.translation.inc file, so the call to _locale_translation_default_update_options() then fails. Included that here as well.
Comment #4
nicxvan commentedThis looks good. I think this qualifies as a fix without the test only.
Do we want a follow up where we add the translations to the fixtures?
I think we got most of the includes back in where they belong. I'll do another pass comparing 11.3 to 11.4 to make sure we captured all of the other automatic includes.
Comment #5
nicxvan commentedOk I took another pass, I think we can address anything else in a follow up.
Comment #6
nicxvan commentedLet's get this in!
Comment #7
quietone commentedTrying for a descriptive title for the commit log.
Comment #8
berdir@quietone: the commit message will be prefixed with "fix: ", no? So I usually the describe the problem/bug in the issue title and not the solution.
Comment #12
catchCommitted/pushed to main, 11.x , and 11.4.x, thanks!