Making a WordPress plugin available in a user’s preferred language used to be more complicated. Now it’s really easy. I want to share the up-to-date way (as of 2019) to get your plugin ready for translating into everyone’s languages.
I’ll skip the complexities of translations and get right to it.
In your plugin’s readme.txt file, add
Requires at least: 4.6 . Here’s an example of a plugin’s readme.txt file:
=== Print My Blog === Contributors: mnelson4 Tags: print, pdf, backup Requires at least: 4.6 Stable tag: trunk Tested up to: 5.0 Requires PHP: 5.4 License: GPLv2 or later License URI: https://www.gnu.org/licenses/gpl-2.0.html
(As a reminder, the readme.txt file is different from the plugin header comment.)
Requiring WordPress 4.6 allows your plugin can take advantage of all the latest simplifications for translations. If you need your plugin to work with older versions of WordPress, then sorry: this tutorial won’t help you. In that case, you’d be best reading the developer documentation.
If your Plugin is in the WordPress plugin repository, WordPress will take care of a lot of the complexity for you. If you don’t want to put it in there, again, sorry these simplified steps won’t work for you.
So, follow the steps for getting your Plugin into the repository. Don’t worry about translations yet, just get it into the plugin repository in English.
Now, in your plugin’s code, use WordPress’ translation functions. For example, instead of doing
$my_string = "foo bar"; in your PHP, and
<b>foo bar</b> in your HTML, do
$my_string = __("foo bar", "your-plugin-textdomain"); in your PHP and
<b><?php _e("foo bar", "your-plugin-textdomain");?></b> in your HTML.
Read more about WordPress translation functions if you’re not familiar with them.
The important part is using the correct translation domain. Go to your plugin’s page on the WordPress plugin repository. The URL will be like https://wordpress.org/plugins/your-plugin-slug/. That last part of the URL, “your-plugin-slug”, is your plugin’s slug. That’s what you use for the translation functions’ text domain.
For example, I have a plugin located at https://wordpress.org/plugins/print-my-blog/. So it’s slug is “print-my-blog”. So when I use translation functions, they look like
$my_string = __("foo bar", "print-my-blog");.
If you do the above steps, WordPress will take care of:
- Parsing through your Plugin for all the translatable strings (no need to install and run Poedit or anything)
- Make it easy for anyone to contribute translations of your plugin on translate.wordpress.org (no need to have your own site dedicated to translating your plugin, or having a custom process for translators to submit their translations to you)
- when someone uses your plugin, WordPress will take care of checking if it’s translates into their language, and if so, showing it in their language (no need for them, or you, to load the translation files onto their website)
For more info, please read How to Internationalize Your Plugin.
Let me know if this could be clearer or I got anything wrong.
After all the above, your plugin is ready to be translated on translate.wordpress.org. BUT translations made there need to be approved by a Project Translation Editor (PTE). If you would like to approve translations for a language you speak for your plugin you need to request that on make.wordpress.org/polyglots, and someone from the language’s team will get in touch. (Eg here’s where I requested to become a PTE for the French and Spanish).
Anyways, that’s it. C’est tout. Terminado. Finito.
Update: I originally titled this “The really lazy way to translate a WordPress plugin”, but despite preferring that name, I realize very few people will be searching for the term “lazy.” “Easy” is much more common and truer to the point of this article.