Thursday , 18 April 2024

Internationalize your WordPress plugin

WordPress plugins allow you to easily modify and enhance your blog by bringing new functionality not otherwise available in the base code.

Using plugins works more effectively than trying to modify the overall core programming that makes up WordPress. Defined as a program or a set of functions written in PHP, plugins add specific features that can easily be integrated with the blog through the WordPress API.
If you have written a WordPress plugin, you can make it much more accessible by translating it into another language. This is known as internationalization.

Internationalization vs. localization

Before you can internationalize your plugin, you must know what it means. Also known as i18n, this means modifying the plugin so that other cultures that speak other languages can easily use your plugin.
Localization by contrast, is the actual process of modification.
There is more to internationalization than just translating the interface. For example, assumptions you have made about imperial units and metric units, punctuation such as using a comma to separate thousands instead of a period, as well as other cultural topics need to be addressed before you can properly localize your work.
While this is a guide that addresses preparing to localize a plugin, it is still important to keep these additional adjustments in mind.

Domains and initialization

Localizing your plugin means you need to come up with a text domain, keeping each one separate from the ones that WordPress uses or that other plugins have defined. Whatever you want to use for a text domain is down to you, but you will want to pick something both unique and sensible, related to what your plugin is about.

Before you can fully localize your plugin, you need to make it tell WordPress how it can find your strings. If the code does not already exist, you will need to insert something like the following line into your coding:

add_action( 'init', 'myFunction' );

This code communicates with WordPress to tell it to use the function called myFunction once it loads. This function then names your text domain to WordPress and teaches it how it can load the localized strings, which should appear similar to this:

function myFunction() {
    load_plugin_textdomain( 'mytextdomain', 'wp-content/plugins' );
}

The WordPress function load_plugin_textdomain informs WordPress that there is a text domain called mytextdomain, and the files that have the localized strings rest within the server folder wp-content/plugin. (Naturally, if you put your plugin files in a different folder and path, you will need to replace this with the appropriate path.)

02

Preparing strings

Following the initialization, you will need to change the static strings to a function that permits WordPress to use the proper localized version of that string. After all, it does not work well to have WordPress pull the wrong language.

This function offers a short name that makes it easy to internationalize: the double-underbar function _(string, domain). The function has two parameters, the first being the default string the plugin uses should there not be a localized version available. The second parameter is the same text domain that you selected in the code earlier.

Prior to this step, your code may appear like this:

function addMyAdminPage() {
    add_options_page(
        'A Page Title',
        'A Menu Title',
        7, __FILE__, 'myAdminFunction' );
 }

After adding the code, it may seem like this:

function addMyAdminPage() {
    add_options_page(
        __( 'A Page Title', 'textdomain' ),
        __( 'A Menu Title', 'textdomain' ),
        7, __FILE__, 'myAdminFunction' );
 }

01

Localization

With all of the preparation out of the way, you are finally prepared for the actual process of turning your WordPress plugin into multiple languages.

Creating a localization for your plugin requires making a .po file with a name similar to your plugin file name as well as the ISO 639 2-letter codes for each country and language. For instance, if your plugin were called examplename and you wanted to localize it to Spanish (European), it would appear as “examplename-es_ES.po”.

While the WordPress codex offers tools that can assist with localization, it is often better to simply go with the .po file from one plugin as a starting point. .po files are made of a single header and then translation pairs:

msgid "Options"
msgstr "Opciones"

The msgid is the standard string that appears in the double-underbar function you dictate. With the .po file created, you can use one of the tools WordPress offers to create a .mo file, which is the other file that WordPress requires.

Letting other translators help

Nobody knows every single language, so you’ll want to expand your resources and let other people help translate into other languages. However, you will need to undergo a special procedure to generate the necessary files to give to your translators since you do not want them to have your source code to accidentally break.

The file you want to give to translators is a POT file, which looks similar to this:

#: wp-admin/admin-header.php:49
msgid "Options"
msgstr ""

There are two ways to generate this file. If you’ve put your plugin into the repository, just head to the admin page and select “Generate POT file”. This file is what you will send to translators for them to localize, though you will likely want to send your plugin with it so translators do not need to ask you questions about the plugin.

php makepot.php wp-plugin the-plugin-directory

Testing

With all of your localized files in place, it is time to test them out and see if there is anything you forgot. Testing your localization means changing a simple line on your WordPress configuration in order to trick it into thinking it should use a different file. Change the file wp-config and locate the following line:

define ('WPLANG', 'en_US');

If this line did not previously exist, you will want to double check and see that your installation still works fine. If so, return to the file and modify the country and language code. With the previous example, this would be as follows:

define ('WPLANG', 'es_ES');

Leave a Reply

Join us through Social Media