Dokuwiki: Translation problem when extending existing plugin

Created on 5 Apr 2019  路  7Comments  路  Source: splitbrain/dokuwiki

I developed an OpenIdConnect auth plugin extending the auth_plugin_authplain because most of the functionality is the same.

I found that whenever a translation defined by auth_plugin_authplain is requested it cannot be found because the translation files are expected in the current modules lang directory.

Is there a way to adapt the plugin functionality to handle this issue? The expected behaviour would be to search for the translations in the auth_plugin_authplain lang directory.

The related line in inc/PluginTrait.php is $path = DOKU_PLUGIN . $this->getPluginName() . '/lang/';

Feature

Most helpful comment

I'm reopening this because it might actually be a thing we may want to fix in our plugin system. I ran into this myself before and I think it might be better solved in the base plugin instead of having each plugin reinventing the wheel.

All 7 comments

I don't think your usage is supported (and can be discussed in mailing list or forum).

However, you may rewrite $this->lang (it's private) in your __construct().

I'm reopening this because it might actually be a thing we may want to fix in our plugin system. I ran into this myself before and I think it might be better solved in the base plugin instead of having each plugin reinventing the wheel.

Looks like we can add a new parameter to setupLocale to explicitly define $this->getPluginName() (and maybe check if it exists after receiving such a name, if failing fall back to itself), and for developers extending plugins they call setupLocale($use_plugin_name) in _construct?

https://github.com/splitbrain/dokuwiki/blob/032d07bd084da379a4be798f675c57c6a7b80d85/inc/PluginTrait.php#L114

That might also lead to some issues. The following use case: You extend a plugin and want to use its translations but also have your own translations. In this case it is necessary to have translations loaded from multiple directories.

An idea to tackle this (without deeply digging into the code now) could be to first load the translations of the current plugin and then check for parent classes' language definitions like so:

$path = DOKU_PLUGIN . $this->getPluginName() . '/lang/';

$paths = array($path);

foreach (class_parents($this) as $parent) {
    $path = DOKU_PLUGIN . $parent . '/lang/';
    $paths[] = $path;
}


$paths = array_reverse($paths);

Instead of loading translations form a single path setupLocale would loop thorugh multiple paths (in reverse to overwrite the parent plugin's translations) and include the corresponding file(s). Since the translation files do not redefine the $lang variable this should work.

Currently we only talk about translations. Does this problem also pop up with other stuff like configurations etc.?

Yes, I agree that this might be extended to extending everything from parent plugin (which I believe is not considered before). Just not sure if this behavior should be default or optional.

It should not have any impact on existing plugins since the current plugin translations overwrite parent plugin translations. Or are there other dependencies I am missing?

Then I would say calling setupLocale() and loadConfig() explicitly to extend things would be great.

Was this page helpful?
0 / 5 - 0 ratings