In 027a747, #13897 was merged. This was a performance improvement: Instead of calling the (expensive?) Translator::addResource method when creating the Translator instance in the DIC, only an array of resources would be passed to Translator::__construct. Translator::loadResources would then iterate over this array and make the actual addResource call, but not unless Translator::initializeCatalogue is called.

Then, e36f1a7 tries to fix a bug with not reloading the messages. It does so by adding another Translator::loadResources call in Translator::loadCatalogue(), but only does this in kernel.debug mode (assuming messages don't change in prod).

Then, in aa70a94, this loadCatalogue overriden method was removed again and the loadResources-if-in-debug code slipped into the constructor.

I admin that I cannot really follow the ideas behind all these changes. However, the bottom line is that in kernel.debug mode, the resources passed to the constructor are turned into addResource() calls immediately, whereas in production mode this is deferred until initialize()/ initializeCatalogue() are called.

This is a problem for other bundles/extensions that add additional resources to the Translator via addResource() calls (for example added to the DIC): Depending on the kernel.debug setting, these resources will be loaded first or last, which makes the resource override (or "lose" against) other message sources.

Assuming that message source priority should not change between debug and prod, I see the following options:

a) Always add resources passed in the resource_files option in the constructor. Probably defeats the initial performance improvement intention?

b) Always defer adding resource_files until initialize() is called. That way, resources added via addResource() by 3rd party bundles always have a lower priority than resource_files.

c) Change the private loadResources() method in a way that "shifts" the resources before those added by addResource() calls (where they would end up if they were added in the constructor).

Additionally, if in production it is no problem to defer this initialization until initialize() is called, why is it necessary to perform this step in the constructor under kernel.debug?

Update: Suggested fix in #23057