This week in a project, I had the issue, that for plugin was not loaded in the correct language. The project war multilingual with three languages. The default language was German, one of the other two languages was English. Usually when you experience broken translations, all texts are shown in English only. But not this time. The strings from the plugin were always translated to German, the default language, even on the English site.

The project was using WPML to translate the website into two other languages. For all other plugins, the theme and the content, the translation was working as expected. Just not for this one plugin. Finding the issue was not easy, but once found, the fix was rather easy.

The problematic code

Two years ago at WordCamp Berlin 2015, I gave a talk on how to initialitze a plugin correctly. I had a similar issue with missing translation. But in this case, it was always showing the English original strings.

<?php
/**
 * Plugin Name: Broken Plugin
 */
    
// Load translation files.
load_plugin_textdomain( 'broken-plugin', false, 'broken-plugin/languages' );
    
// Initialize plugin.
add_action( 'after_setup_theme', 'broken_plugin_theme_setup', 12 );
    
function broken_plugin_theme_setup() {
	// Some code ...
}
&#91;/php&#93;

I don't want to blame the plugin author for the small issue, so I anonymized the name. But above you can see the code, how it looked like in the plugin. As you can see in this short snippet, the language file is loaded right at beginnig of the plugin file. The plugin has a callback function registered to the <code>after_setup_theme</code> hook, which would be the perfect place to load the translation.
<h2>The reason it is broken</h2>
But why is the translation not working? As I told you, the translation files must must be loaded, otherwise the strings would not be in the default language German, but in English. The reason for that is quite simple. The plugin name started with the letter B (not only my anonymized example, but also the real one) and as plugins are usually loaded in an alphabetic order and the folder name of WPML is "sitepress-multilingual-cms", the plugin and it's code just came too early. The switch to the correct language was only done after WPML was fully loaded. But at this time, the translated strings of the broken plugin were already in the translations array (with the German string) and not overwritten with the correct language.
<h2>Fixing the plugin</h2>
So fixing the plugin would be easy, right? I just have to move the function call of `load_plugin_textdomain` into the callback function. That would work. But what would happen on the next update? Correct! The translation would be broken again.

So how to do it better? The best way to fix it, would be a bug report to the plugin author. This is what I did. I found the plugin on GitHub, fixed the bug on a fork and opened a pull request. But the plugin has some pending PRs and no new release for over two years. So I didn't expected my fix to be released any time soon. So we can now fix it in the plugin ourselves? We could, but there is another way. Why not fixing the plugin from the outwise. Doing this is pretty easy.

Many developers know the function <code>load_plugin_textdomain</code>, but as fix many functions named like this, there is usually a reverse function. In this case <code>unload_plugin_textdomain</code> which we could use:

[php gutter="false"]
function broken_plugin_trail_wpml_fix() {
	unload_textdomain( 'broken-plugin' );
	load_plugin_textdomain( 'broken-plugin', false, 'broken-plugin/languages' );
}
add_action( 'after_setup_theme', 'broken_plugin_trail_wpml_fix', 13 );

So within another callback function to the hook after_setup_theme we just first unload the translation and then load the file again using the exact same call. We use priority higher than the one in the plugin, wo even if the fix is being merged and we don’t recognize it right away, our fix will still work.

This code can be dropped in a small plugin (or temporarily in the functions.php file of the theme) and once the original plugin is fixed, we can remove it.

Conclusion

As you can see from the easy example, you can sometime fix issues in a plugin without changing it’s code, so on a plugin update, the fix will still work. I would still highly recommend, that you always try to provide a fix for the issue to the plugin author first. Some of them are really quick with releasing a patched version of the plugin, so you don’t have to find a way aroud. And even more important: this way you not only fix the issue for your site, but for all the other users who experince that issue.