Plugin Internationalization

Not everyone in the world speaks English. That is especially true and most especially worth considering when developing WordPress plugins, which is why WordPress has built-in functionality to translate text displayed as part of a plugin or theme. The problem is that the plugin or theme developer has to do all of the translation work themselves (or, at least the accommodation part, if others are willing to lend a hand with performing the actual translations.)

How WordPress Handles Internationalization

Internal Routine

Setting up a WordPress plugin to perform internationalization requires just one line of code:

This function defines the plugin internationalization namespace and directory where all of the translation files will be located. For the Unicode Character Keyboard plugin, I put the line in the __construct function as the plugin uses a class-based structure.

• The first parameter defines the namespace: having a unique namespace prevents conflicts with other plugins and their own translations. It is recommended to namecheck the namespace (I use initials) to further prevent conflicts. (I recommend using the base name of the plugin file as the namespace.)
• The third parameter is the directory in which the translation files will be located.

Note: the second parameter should always be false; it is there only for compatibility with previous versions of the function.

External File(s)

This is where things get a little tricky. WordPress uses a specific naming convention for the translation files and then converts these files from text into binary for faster access during page loading.

The naming convention begins with the namespace: whatever was used in the function call as the namespace is the first part of the file name, followed by a dash. The second part is the lower-case ISO 639 two-letter international code for the language: for instance, ‘en’ is English and ‘es’ is Spanish (Español). There is an optional third part, for instances where individual country dialects of languages are taken into account: these consist of an underscore followed by the upper-case two letter abbreviation for the country; for instance, ‘_ES’ would be Spain (España). Finally, the file extensions determine the format of the internal data: ‘.po’ is the readable text version of the translation file and ‘.mo’ is the machine readable version.

For example, the Spanish translation source file for the Unicode Character Keyboard would be ‘avp-unicode-charkbd-es_ES.po’ and the machine-readable file would be ‘avp-unicode-charkbd-es_ES.mo’.