What is my aim?

I'm looking forward to write test cases for the available translations of a WordPress plugin.

My approach:

I have setup WordPress using VVV and my testing suite includes PHPUnit and WP-CLI.

In order to test (assert) the translations, I'm checking if the language's .mo file exists or not.

 * Test the translations.
public function test_translations() {
    $this->assertFileExists( $this->object->path . 'lang/domain-name-de_DE.mo' );
    $this->assertFileExists( $this->object->path . 'lang/domain-name-lt_LT.mo' );
    $this->assertFileExists( $this->object->path . 'lang/domain-name-nl_NL.mo' );

Where I'm stuck?

Is this the right approach to test translations for a WordPress plugin? If not, please suggest alternatives.

1 Answer 1


If all that you want to test is that the translation files exist, then this is probably the simplest approach, since you'll probably already be using PHPUnit to run unit/integration tests on the plugin code.

However, just checking whether the files exist doesn't tell you much. It doesn't tell you whether those languages are actually fully translated, or even if those files will be loaded properly by WordPress.

So the question you need to ask yourself is, "Why am I testing this?" If you just want to make sure that you don't accidentally leave out a translation file, then your tests should do what you need. If you want to actually ensure that you have complete translations for each language, and that these actually work, that's an entirely different story.

Testing translation loading

To check whether each translation file can be properly loaded by WordPress, you could probably create a PHPUnit test that loaded the files using load_plugin_textdomain(), and checking that it returns true, which would indicate that the textdomain could be properly loaded. You'll probably need to hook into the plugin_locale filter to check each locale that ships with your plugin.

Testing completeness

However, that still wouldn't tell you how many of the strings were actually translated into that language, how many are fuzzy, etc. If you want to check that each translation is at least xx% complete, you'll probably want to use a tool other than PHPUnit for that.

Testing appearance

You could also go further and check that the strings in each translation actually appear correctly in the plugin UI. Sometimes a string might be much longer in a translation than it is in the original language, and this can cause it to overflow the area allotted for it. To check this you'd need to use something like Codeception acceptance tests.


So, in conclusion, whether the tests you have are the right approach for you depends on what you want to test. Personally, I don't have any tests for my plugins' translations, although that last part about checking the UI has intrigued me. Just checking that the translations exist, as you are doing now, doesn't appear to me to provide much benefit. It is a check that is only as good as your list of translation files that you are checking for. And in one sense it doesn't actually test anything, just makes sure that it is there. That could be performed in a build script rather than PHPUnit. Checking that the translations can actually be loaded by WordPress does provide benefit IMO, because it actually tests that they aren't corrupted. And of course, it tests that they exist at the same time. So I'd probably expand your tests to check that too.


On a related note, you might also consider testing for any spelling errors in your main POT (and in translations too, I guess). It's easy for these to slip in under the radar. Probably there are shell scripts available that could do this.

  • Thanks for a detailed explanation @j.d. The answer is very helpful. Jul 8, 2016 at 18:01
  • Hello @J.D. in my case I had to check the $plugin_rel_path when loading the plugin text domain - load_plugin_textdomain( $domain, $abs_rel_path, $plugin_rel_path ) So I had to write the test case for it. Jul 21, 2016 at 5:24
  • @MariaDanielDeepak Good idea. I've updated the answer to suggest using load_plugin_textdomain() instead of load_textdomain().
    – J.D.
    Jul 21, 2016 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.