So what should be then the new behavior? That the plugins call loadLanguage by themself at the top of the plugin event function?

That the plugins call loadLanguage by themself at the top of the plugin event function?

Yeap, that what I thought. Should not be hard.

Would mean when a plugin registers on multiple events which are all called in the same request, the language is loaded multiple times?

No, it will load it only once, look:

Maybe until 6.x we will come up with some smarter idea to load it automatically, without breaking everything :)

I have no problem moving it to the event function as constructors should have as less logic as possible and shouldn't do heavy tasks. Especially this one here is usefuel as when the event is not called in a plugin, the language is not called.

This is going to seriously break plugins and so we can potentially add new plugins further up in the stack? Sounds odd to me?

This is going to seriously break plugins

I do not see it that much critical. Plugin will be able to load language manualy. If they missed it (in J6), then it will be shown untranslated strings. Nothing will explode.

In future (in J 6) it would throw an excaption if someone try to load language before application is initialised.
In any case, the correct language available not early than onAfterRoute event, if I right.

Having it in constructor just not right.

I have made alternative #40355 (to 5.0-dev), please review, and choose what is better.

The changes in loadLanguage should be reverted, on some point we want to inject the language directly. Loosens a bit the dependency to the application god object then. The rest looks ok.

Unfortunately we cannot inject Language in to plugin.
The plugins should be able to run at any stage of Application existence, however the language available only "after initialise" stage.

I am closing it in favor of #40355, that introduce zero b.c. break.