#49807 closed defect (bug) (worksforme)
load_plugin_textdomain() expects a path relative to plugins/, making i18n for mu-plugins difficult
Reported by: | theMikeD | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | I18N | Keywords: | |
Focuses: | Cc: |
Description
Looking though the code for load_plugin_textdomain()
(https://core.trac.wordpress.org/browser/tags/5.4/src/wp-includes/l10n.php#L797) I can see that it is expecting to receive a path relative to the plugins folder, as defined by WP_PLUGIN_DIR
.
All fine as long as the plugin is located within the folder defined by WP_PLUGIN_DIR
...but mu-plugins are not; they are typically in a folder parallel to WP_PLUGIN_DIR
but they can be anywhere via the WPMU_PLUGIN_DIR
define.
This makes it very difficult to add a text domain to a mu-plugin, since the only way I have so far found is to pass a relative folder, such as ../mu-plugins/plugin-folder/languages
, which is problematic because it's making assumptions about the setup.
Together with the apparently missing easy way to determine if a plugin is loaded normally or as part of the must-use loader, it's impossible to write load_plugin_textdomain()
in a generic way that accounts for mu-plugins.
The solution would seem to be to un-deprecate the second argument, but I'm not aware of the discussion around why it was removed.
I hope someone can point out something easy I have overlooked!
Hello @theMikeD, for mu-plugins you can use load_muplugin_textdomain().