If you didn’t write the plugin – how do you translate it? I found lots of information for plugin developers to make their plugins translatable but not for people that just want to translate it.
Executive summary / tl;dr
Edit: The Codestyling Localization plugin I suggested previously isn’t available from WordPress directly any more.
Instead there seems to be an equally good plugin Loco Translate that is complemented by the developers own site for translating any application.
Failing that try the ‘Blank WordPress POT’ with POEdit and put that in the plugin’s languages directory. This seems to be a rock solid approach but takes a bit of learning.
If you put your translations in the plugins language directory, you’ll lose your translations when the plugin gets updated. Either keep backups or, if the plugin loads the translations correctly, you can put your translations in the separate
For worker ants who want to know a bit more
- The plugin must be translatable (It has been internationalized)
- You can check this by looking through the plugin code
- Otherwise just carry on and hope that the developer made it translatable
- Then you need to create a translation file that converts the English words into your language (localize it)
- A POT (.pot) file is a skeleton file that contains all the words and phrases in the plugin that can be translated
- A .po file is a .pot file that has had the translated strings in your language added next to each of the translatable phrases
- When you save a .po file it also generates a .mo file (where as you can read a .po file in notepad you can’t read a .mo file)
- WordPress plugins rely on .mo files
- You first need to find the .pot file
- Typically this will be in the root of the plugin directory
- Or it will be in a languages directory
- If you find it, great. Open it in POEdit, do your stuff and save
- If it hasn’t been created at all …
- … Then you need to check in the code (look for
load_plugin_textdomainin the main plugin file) to see where/if you should create one and create the .pot file yourself
If you don’t know about editing PO files I suggest following the WordPress instructions on using POEdit.
For developers to ‘internationalize’ their plugins
I recommend using the Blank WordPress POT file that I mention below in the POEdit revisited section.
- https://make.wordpress.org/docs/plugin-developer-handbook/15-internationalization/how-to-internationalize-your-plugin/#loading-text-domain This is the main bit of code that needs to be added into any plugin and is the start for looking into a plugin to see where the translations should go
- https://en.wikipedia.org/wiki/Gettext The fundamentals behind the
- https://premium.wpmudev.org/blog/localize-a-wordpress-plugin-and-make-it-translation-ready/ Recommended reading by the WordPress codex pages – but the POT file you create doesn’t seem to work
- https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/#best-practices-for-writing-strings phrases not words, and
printfis your friend
Initially I tried the POEdit method recommended in WPMU DEV tutorial
However the POT files that I made never worked – they didn’t pick up the translated words. I think it was because of
_e() instead of
and Tom McFarlin talk about using makepot.php but its confusing if you’re not using Linux
- It requires using the
wp-pluginas the project name which I assumed that you changed to the name of your plugin but you don’t – it has to stay wp-plugin
so the required command is (for windows):
php makepot.php wp-plugin path\to\plugins\your-plugin-name
- However I got the following error when running it from windows
'msguniq' is not recognized as an internal or external command
- This appears to be because
msguniqis a linux command
- Actually this had created the
your-plugin-name.potfile in the plugin directory but I just didn t realise because of the error
- If you do want to use makepot.php use grapper’s Github i18n repo which includes all the correct WordPress files rather than the official WordPress subversion directories.
That can be put in the plugin’s languages directory and has instructions for creating the PO files from it:
The pot file include in this folder is ready to use.
- Double click on it and open it with poedit
- In poedit goto File → New Catalog from POT file…
- Select and Open the pot file from the languages folder
- Enter your name, email address, your language and country (i.e. french fr_FR, german de_DE) to the setting form
- Click the update button in the main poedit ui.
- Save the file :
- For a plugin like filename-xx_XX.po with xx_XX for your language and country.
- For a theme xx_XX.po
- That’s it, go to your WordPress blog and see your translation in action. N’joy your blogging!!!
This actually worked first time that I tried it – i.e. it pulled in all the translated strings.
First off you can then save the file as a my-plugin-name.pot file in the languages directory. Then you can add in your translations and save it with the locale xx_XX.po file ending and that should generate the
.mo file that you need too.
Edit: The simplest route was via the Codestyling Localization plugin.
But that is no longer available through the WordPress plugins directly – possibly because it isn’t working or from a security issue. It is still available via the developer’s own site though
Instead you can use Loco Translate which appears to be excellent – but I haven’t tried it.
(These are old instructions for Codestyling Localization) Once it is installed:
- Click ‘Add New Language’
- Select your locale and it generates an empty
- Click ‘Rescan’ to populate the
- Click ‘Edit’ and ‘generate mo file’ to get the
Dealing with plugin updates
None of this solves the problem that you will lose your translation files once when the plugin is updated.
.po files into the
wp-content/languages/[plugin-name] directory – which might or might not work. If yes, great, if not raise a support query (be nice and give details) with the plugin developer.
This directory is update safe basically because of the translations are loaded with the following priority:
wp-content/languages/[plugin-name](never changed by updates)
wp-content/languages/plugins/(changed with updates)
wp-content/plugins/[plugin-name]/languages(changed with updates)
If developers follow this Geert DeDeckere’s excellent guide on loading WordPress language files the right way then there shouldn’t be a problem with using the
You can also read WooCommerce’s documentation on Making your Localization upgrade safe which recommends either Loco or using
I found these two Support questions useful for learning about handling upgrades: