Translations not being loaded for mu-plugin and theme

  • Hi all.

    For both a mu-plugin and a theme I’m trying to include translations. For the mu-plugin I’m using the load_muplugin_textdomain function and for the theme I’m using the load_theme_textdomain function. I put the mo-files in the /languages directory in the mu-plugin and theme itself.

    Though still the translations aren’t being loaded. I dug into the load_textdomain function and found out that the mo-files for both the mu-plugin and theme are being added to the $i18n global. I also checked in the load_textdomain if the actual mo-files are being found (using the file_exists function) by the function. And they are in both cases.

    When I add the mo-file for the theme in the main-languages directory everything is fine and the translations do work. This isn’t the case for the mo-file for the mu-plugin.

    While I was testing this I only had one plugin active called “Classic Editor”. Next to that I’m running WordPress 5.9.

    I hope someone can help because I’m clueless about this.

    • This topic was modified 2 years, 8 months ago by Jan Dembowski. Reason: Moved to Fixing WordPress, this is not an Everything else WordPress topic
Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator bcworkz

    (@bcworkz)

    Did you check the $l10n (localization) global? Not $i18n. I think that’s what you intended to say, I often make the same mistake. If $l10n contains your translation strings, then they were loaded correctly. It’s essentially all load_textdomain() does. The remaining translation functionality is up to gettext() and its variants. When you use __() and its variants, ensure the $textdomain parameter matches your plugin’s slug name, as should the $domain parameter passed to load_muplugin_textdomain().

    Slug names must comply with naming rules — only plain lower case alpha-numeric and -, no special chars or whitespace.

    Thread Starter ReHo20

    (@reho20)

    Hi bcworkz.

    Thanks for your quick response. I indeed meant the $l10n global. The slugname for the mu-plugin only contains an - and for the theme it’s not containing any special characters at all. And both $textdomain do match the slug of the theme/mu-plugin they belong to. And I later found out that the mu-plugin .mo file also loads from the general language directory correctly (and visibly changes the texts). So the big question is still why the MO-files in the language directory of the theme and mu-plugin themselves are loaded into the $l10n global correctly. But doesn’t visibly change the texts.

    I am using a slightly different directory structure for WordPress (Bedrock). Though I don’t think that it is causing the issue.

    Moderator bcworkz

    (@bcworkz)

    As I said, if $l10n is correctly populated, then the issue lies somewhere within the gettext() process.

    Translations::translate_entry() is where the translation is determined for the text passed from __() and related functions. You could work back out from there using the links in the Related/Used By section. You could temporarily alter the source code to add error_log() and similar debugging code to trace out the process and determine exactly where and how things go awry.

    One strong possibility is there are a number of filters like “gettext” where plugins or themes can alter normal translation behavior. Instead of the debugging process suggested above, you could instead start at “gettext_{$domain}” and work either out or in, depending on whether the filter is returning a proper translation or not.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Translations not being loaded for mu-plugin and theme’ is closed to new replies.