When you create a WordPress plugin for general distribution, it is always good practice to make it multilingual. Basically you need to make sure that it is easily translatable. You will be surprised at how many users will chip in to help you produce the language files for your plugin, if you have got a good user base of course.
So how do you localise and translate a WordPress plugin?
First of all, rest assured, this is not going to be a painful process, nor is it that time-consuming. There is really no excuse not to localise your plugin.
Let’s get the terminology straight first of all.
Multilingual: A website/theme/plugin which is available in multiple languages.
Translation: The act of preparing more than one language file, containing all text used in your plugin.
Internationalization (i18n): Preparing your plugin for eventual translation. This is what we are interested in here.
Localisation (i10n): Once we are ready from Internationalisation (I18n), we can then proceed with localisation, which refers to the actual translation from one language to another.
The first step is to go through the plugin and localise it. This means that we need to take a look at all strings and use some special functions there.
Secondly we provide a translation file and create a languages folder.
Use the load_plugin_textdomain function
To start off, we need to include the load_plugin_textdomain function in our plugin. This function loads the plugin’s translated strings.
The function call will look something like this:
load_plugin_textdomain( ‘my-plugin’, false, dirname( plugin_basename( __FILE__ ) ) . ‘/languages/’ );
Replace Strings Used in Plugin
We now have to check for strings in our plugin and change them slightly in order for them to be translatable.
So for example, this line:
add_submenu_page( ‘edit.php?post_type=wprss_feed’, ‘WP RSS Aggregator Settings’, ‘Settings’, ‘manage_options’, ‘wprss-aggregator-settings’, ‘wprss_settings_page’ );
add_submenu_page( ‘edit.php?post_type=wprss_feed’, __( ‘WP RSS Aggregator Settings’, ‘wprss’ ), __( ‘Settings’ ), ‘manage_options’, ‘wprss-aggregator-settings’, ‘wprss_settings_page’ );
Have you noticed what we’ve done here? We have wrapped our strings within the __() function. This is a WordPress function that fetches the translated strings for us.
It’s definition is:
<?php $translated_text = __( $text, $domain ); ?>
Adding a TextDomain
Adding your domain as an argument to the functions we’ve used is required. Since this is a real drag to do, I suggest using the add-textdomain.php script which searches through your code and adds the textdomain to your translatable strings.
- If your plugin is registered in the official repository, go to your Admin page there and scroll to Add Domain to Gettext Calls.
- Get the add-textdomain.php script and execute it like this:
You now need to download a program called POEdit, which is totally free.
Setting it up is pretty straightforward, and we’ll be using it to prepare a catalog of all the strings that can be translated within our plugin.
Here’s an excellent guide on how to use POEdit when localising WordPress plugins.
POEdit is usually your last step in localising your plugin. Once you have your .po file ready, you can ask translators to start helping you out, the default.po file is all they need to translate the strings and save a new .po file with their language.
Once you’ve completed your plugin localisation process, I suggest you contact WPML because they have a reviewing service that will be tremendously useful to you. Basically they go through your plugin’s code and make sure that the localisation is done well. They offer this service to make sure that as many plugins and themes as possible are compatible with their fantastic WPML multilingual plugin for WordPress.
Here’s the link to their Go-Global program
More Resources About Multilingual WordPress
If you enjoyed this post, make sure to subscribe to WP Mayor’s RSS feed.