Locale::setLocale() logs InvalidArgumentException even for valid, installed locales during early request lifecycle

Software Support
1

Environment:

Describe the issue

The error log is repeatedly flooded with entries like:

InvalidArgumentException: Invalid/unsupported locale "en", default locale restored in .../lib/pkp/classes/i18n/Locale.php:155

This occurs even for locales that are correctly installed and enabled on the site/journal (confirmed via site.installed_locales / supported_locales, and the corresponding physical locale folders). It appears to fire during early plugin/theme registration (e.g. ThemePlugin->init()), before the request’s journal/site context is fully available to isSupported(), causing a false-positive rejection that is logged before falling back to the primary locale.

This matches the behavior already reported at the link above (originally observed with locale "en" and "fr" triggering the same false positive in our installation), where a community member confirmed the same symptom on 3.5.0-4.

Impact

The resulting log noise makes it very difficult to spot genuine, actionable errors in production error logs, since this notice can fire dozens of times per minute on a multi-journal installation.

Current workaround

As also suggested in the forum thread, we’ve locally commented out the error_log() call in lib/pkp/classes/i18n/Locale.php, in setLocale():

php

public function setLocale($locale): void
{
    if (!$this->isLocaleValid($locale) || !$this->isSupported($locale)) {
        if ($locale) {
            //error_log((string) new InvalidArgumentException("Invalid/unsupported locale \"{$locale}\", default locale restored"));
        }
        $locale = $this->getPrimaryLocale();
    }
    ...
}

This does not fix the underlying validation timing issue, it only silences the noise, and the fallback behavior continues to work correctly.

Suggested direction for a proper fix

Per the original reporter’s note: this notice should probably only be logged if the locale is genuinely not installed anywhere on the site (not per-context), and/or the check should not run before the request context (journal) is fully resolved. Happy to test a patch if one is proposed.

Note: This report was drafted with the assistance of an AI (Claude), based on debugging carried out directly on our production error logs. The described workaround has been applied and tested on our own installation.