InvalidArgumentException error when journal does not use site level default locale

[ajnyga]

Hi,

It seems that the CitationStyleLanguage plugin does not behave well if a journal is using a locale that is not the default locale of the OJS site.

For example in our case the site level locale is fi and the only locale that the journal is using is en.

This causes a lot of errors like:
[06-Nov-2025 11:40:46 Europe/Helsinki] InvalidArgumentException: Invalid/unsupported locale "fi", default locale restored in lib/pkp/classes/i18n/Locale.php:144

Enabling the fi locale in the journal removes the errors.

This is in 3.4 stable.

ping @asmecher, you maybe handle this plugin?

[asmecher]

@ajnyga, I replicated your setup (site-wide fi locale, one journal with only en, another with only fi, citationStyleLanguage enabled on both) and couldn't replicate this issue. Could you dig a little deeper and see if you can determine the cause?

[ajnyga]

Hi,

Ok, so I found it finally. This maybe applies to other plugins as well.

This is how I produced it in a clean 3.4 stable release.

1. Create the site. Set Site Default Locale to finnish
2. Create two journals
3. Journal A - Primary language Finnish, secondary language English
4. Journal B - Primary language English - no other languages enabled
5. Enable the language switchers for the journals

To bring out the error, edit the Default themeplugin (like I mentioned this probably applies to other plugins)

Add this to the init in the plugin. The point here is to have that translation triggered.

		$this->addOption('mainTitle', 'FieldText', [
			'label' => __('plugins.themes.default.option.typography.label'),
			'description' => __('plugins.themes.default.option.typography.description'),
		]);

When this is ready, log in and follow these steps

1. Go to Journal A and select the Finnish language
2. check your session data and see that currentLocale is set to fi
3. Go to Journal B and the error should appear.

So the root cause seems to be that the system tries to use the locale stored to the session first but gives the exception. This is maybe not causing any further problems, but is way too loud for the error logs.

The key is this code. I do not think we should return the currentLocale if the locale is not supported in the current context.

    /**
     * @copy \Illuminate\Contracts\Translation\Translator::getLocale()
     */
    public function getLocale(): string
    {
        if (isset($this->locale)) {
            return $this->locale;
        }
        $request = $this->_getRequest();
        $locale = $request->getUserVar('setLocale')
            ?: (SessionManager::hasSession() ? SessionManager::getManager()->getUserSession()->getSessionVar('currentLocale') : null)
            ?: $request->getCookieVar('currentLocale');
        $this->setLocale($locale);
        return $this->locale;
    }

    /**
     * @copy \Illuminate\Contracts\Translation\Translator::setLocale()
     */
    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->locale = $locale;
        setlocale(LC_ALL, 'C.utf8', 'C');
        \Locale::setDefault(\Locale::lookup(ResourceBundle::getLocales(''), $locale, true));
    }

[asmecher]

@ajnyga, thanks for tracking this down. Since you're already in the weeds, and it sounds like perhaps a one-liner adjustment to that function, would you mind proposing a PR?