User tests: Successful: Unsuccessful:
Alernative to #40309
The patch moves language loading out from CMSPlugin constructor.
This makes the constructor lighter and probably esier for tests, also allows to restore #27155.
Apply patch, and make sure all works as before. All plugins translated.
Please select:
Category | ⇒ | Libraries |
Status | New | ⇒ | Pending |
Title |
|
Accessing language in constructor of the System plugins should be forbiden (and for any other group also).
Because the Language available not early than afterInitialise.
That will limit the plugin usage, and will not allow to use it for early stages. And this is a main reason why I tries to move language loading out from constructor ;)
Labels |
Added:
Feature
bug
PR-5.0-dev
|
I have tested this item ✅ successfully on 2bf6090
I applied patch, logged in with German selected and opened several plugins - all strings were in German. Is that a valid test?
I'm not so happy to merge this in to 5.0 anymore, since it would effect existing plugins depending for the loaded language in the constructor. I think we have to postpone this to 6.0 or find a better b/c way.
Yeah, it would be need before first alpha :)
But I thinking to moving it in to bootPlugin()
, will be smarter.
if ($plugin->autoloadLanguage()) {
... here some code for checking if language is ready, then:
$plugin->loadLanguage();
}
For 6 or maybe can get in one of 5.x.
Loading language in the plugin constructor is very bad.
This pull request has been automatically rebased to 5.1-dev.
Title |
|
Labels |
Added:
PR-5.2-dev
Removed: PR-5.0-dev |
I have changed approach, should be better now.
This pull request has been automatically rebased to 5.3-dev.
Title |
|
I think it's not a good idea to force the application in the plugin to load the languages, wouldn't it be better to provide the language in the register process?