Use 'load_language' property as a flag to load the language files

[okonomiyaki3000]

So that the constructor doesn't need to be overridden for this purpose.

It seems that almost all plugins override the constructor just to load language files. Now you will be able to simply set a property to true and they will be loaded automatically.

[eddieajau]

Is there any reason why this couldn't be done via the $config array? Also, is it worth moving JPlugin to the legacy tree?

[okonomiyaki3000]

In order for it to be done via the $config array, this option would need to be part of the plugin's params. I suppose it's possible to do it that way but params are typically meant to be set up by the user, right? Loading the language isn't something that should be at the user's discretion generally.

I'm not sure what you mean about the legacy tree. Would this change necessitate that?

[eddieajau]

Loading the language isn't something that should be at the user's discretion generally.

I guess not, but then I'd argue it's at the discretion of the plugin developer. It honestly doesn't bother me, I just wouldn't include it because plugins don't usually have to load language files.

[okonomiyaki3000]

Indeed, this leaves it at the discretion of the developer as it is now. The current situation is that, if a plugin needs language files, the developer typically overrides the constructor just to call loadLanguage. That means the parent constructor also needs to be called. So by using this property as a flag, we can save developers a minor hassle and reduce the overhead of calling additional functions.

It seems that about half of the plugins that ship with the CMS are overriding the constructor just for this purpose. Probably many third party plugins are as well.

[elinw]

Plugins need language files if they need configuration and also if they have to send any messages, and of course form plugins almost always will have labels and descriptions. Depending on the application they might have something like a success message on installation as well. So I think it's reasonable.

[eddieajau]

plugins almost always will have labels and descriptions

Yes, but those language files are handled by com_plugins. Otherwise I just don't think it's a big deal for developers to have to load the language on demand. But like I said, it doesn't bother me.

I'll get you a determination on whether the maintainers want to move this package to the legacy tree (/libraries/legacy/plugin) as soon as I can.

[eddieajau]

I'd probably prefer to see this variable in camelCase $loadLanguage. We should only use underscore separators in things like column names.

[okonomiyaki3000]

Isn't it kind of gross to use the same name for a property and a function?

[pasamio]

Then make it autoloadLanguage which is slightly more descriptive for the property.

[eddieajau]

Deal!

[okonomiyaki3000]

Good thinking!

[elinw]

@eddieajau why do you think there will always be a com_plugin? But yeah you're right on that. I do think that the application probably has to implement a way to respond to triggers so you're totally right on the idea that it should handle the language for those kinds of things, but I will say that there will in general be language though so to +1 to this.

[elinw]

@okonomiyaki3000 Would you send this as a pull request to the cms?

[okonomiyaki3000]

CMS pull request is here: joomla/joomla-cms#698