Internationalization & Localization


–   It is the process of developing your plugin so it can easily be translated into other languages.

–  In general term, internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.

–   As wordpress is used world-wide, plugins developed by any developer should be translatable in any language without playing with the source-code itself.

–   Internationalization is often abbreviated as i18n (because there are 18 letters between the i and the n).



–   Describes the subsequent process of translating an internationalized plugin.

–  Generally, localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale).

–   It is the process of converting any internationalized plugin to the local language.

–   It is abbreviated as l10n (because there are 10 letters between the l and the n.)

–   It is second process i.e. plugin must be internationalized before localization process is done.



Because WordPress is used all over the world, it is a good idea to prepare a WordPress plugin so that it can be easily translated into whatever language is needed without modifying codes.

Helpful for the users who are present in any corner of the world with any tongue but still want to use that internationalized plugin.

Internationalization significantly affects the ease of the product’s localization. Retrofitting a linguistically- and culturally-centered deliverable for a global market is obviously much more difficult and time-consuming than designing a deliverable with the intent of presenting it globally.


When to internationalize & localize?

The goal of internationalization and localization is to allow a product i.e. theme or plugin to offer its content in languages and formats tailored to the audience.

If we are taking our themes or plugins to international level so that everyone can use it then we internationalize it. Later on it is localized by the translator. In other words, if our target is each & every market or wordpress users around the globe then we have to internationalize the plugin & themes we have developed so that they can be localized later by the local translator in their own language.

How to internationalize plugin?

Step 1 – Loading translation files

The very first step when creating a theme is to load translation files, there are many ways to do it, but the simplest is using this code:

add_action(‘after_setup_theme’, ‘my_theme_setup’);

function my_theme_setup(){

load_theme_textdomain(‘my_theme’, get_template_directory() . ‘/languages’);


When working on a plugin, it’s pretty much the same thing:

function myplugin_init() {

load_plugin_textdomain( ‘my-plugin’, false, dirname( plugin_basename( __FILE__ ) ) );


add_action(‘plugins_loaded’, ‘myplugin_init’);

Now that the files are loaded under a “languages” folder, you can create a .pot, or .po file using POedit free software.

Step 2 – Translating strings

When you need a string be translatable, you need to include the string contain into a function. The most used functions are _e() and __(). Here is a sample of to use __():

echo ‘<p>’ . __( ‘This is the string content’, ‘textdomain’ ) . ‘</p>’;

What does this function is returning the string contain, but it doesn’t print it. That’s why we need to use echo. But the _e() function is printing the string contain without using echo or print:

echo ‘<p>’;

_e( ‘This is the string content’, ‘textdomain’ );

echo ‘</p>’;

Step 3 – Translating string containing variables

But sometimes your string might contain variables. Using _e() and __() does not work. So, in that case you need to printf() and sprintf() functions. As we saw earlier, printf() echo the string while sprintf() store it.

echo ‘<p>’;

printf( __( ‘I bought %d books.’ ), $_books_count );

echo ‘</p>’;

echo ‘<p>’;

echo sprintf( __( ‘I bought %d books.’ ), $_books_count );

echo ‘</p>’;

Step 4 – Strings with more than one variable

In the case of a string containing more than one variable, use the following code:

printf( __( ‘I bought %1$s books, and %2$s tomatoes.’ ), $books_count, $tomatoes_count );

Step 5 – Dealing with plurals

In the example above i bought books and tomatoes. But what i bought only one book? The code will print “1 books”, and this is not correct. So, to deal with plural, there’s another function called _n(). Here is how to use it:

printf( _n( ‘i bought %d book.’, ‘i bought %d books.’, $books_count ), $books_count );

Step 6 – Contexts

Sometimes, a word can have different meanings dues to its context. You can then use these functions _x() and _ex(). The second one echo the string while the first one only store its content. These functions have a second argument to explain it’s context. Fo example if a word is used twice in a page but has different meanings in the content and in the sidebar, then your code would look to something like this:


APPARENT (obvious vs. not clear) — It was apparent to all, Joe was the apparent loser.

Two different contexts for the word “apparent”


// In the content

echo _x( ‘apparent’, ‘in_content’, ‘my-plugin-domain’ );

// In the sidebar

echo _x( ‘apparent’, ‘in_sidebar’, ‘my-plugin-domain’ );

Step 7 – Javascript internationalization

And finally when you have a string to needs to be translatable in a javascript file you can use a method defined in the codex using wp_localize_script().

// In your PHP file:

wp_enqueue_script( ‘script-handle’, … );

wp_localize_script( ‘script-handle’, ‘objectL10n’, array(

‘speed’ => $distance / $time,

‘submit’ => __( ‘Submit’, ‘my-plugin-domain’ ),

) );

// in the javascript file:


$(‘#speed’).val(‘{speed} km/h’.replace(‘{speed}’, objectL10n.speed));

Simply replace your own variables and you’re done!

Localization files

POT (Portable Object Template) files 

This file contains the original strings (in English) in your plugin. Here is an example POT file entry:

#: plugin-name.php:123

msgid “Page Title”

msgstr “”


PO (Portable Object) files 

Every translator will take the POT file and translate themsgstr sections in their own language. The result is a POfile with the same format as a POT, but with translations and some specific headers. There is one PO file per language.

 MO (Machine Object) files

From every translated PO file a MO file is built. These are machine-readable, binary files that the gettext functions actually use (they don’t care about .POT or .PO files), and are a “compiled” version of the PO file. The conversion is done using the msgfmt tool. In general, an application may use more than one large logical translatable module and a different MO file accordingly. A text domain is a handle of each module, which has a different MO file.

Generating POT file

The POT file is the one you need to hand to translators, so that they can do their work. The POT and PO files can easily be interchangeably renamed to change file types without issues. It is a good idea to offer the POT file along with your plugin, so that translators won’t have to ask you specifically about it. There are a couple of ways to generate a POT file for your plugin:

Plugin Repository Admin Tools

If your plugin is registered in the official plugin repository, go to your “Admin” page there and then click on ‘Continue’ by the “Generate POT file” section.

Leave comment

Your email address will not be published. Required fields are marked with *.