The very last thing you need to do is to load the plugin's text domain. This is the function that makes the translation go; it passes all your gettext-wrapped strings through the language file (if it exists) matching the user's language as set in his or her configuration. The necessary code is shown in Listing 9-33.
Listing 9-33. The i18n functions if (!defined('WP_PLUGIN_DIR'))
define('WP_PLUGIN_DIR', dirname(dirname(__FILE__))); $lang_dir = basename(dirname(_FILE_)). '/languages';
load_plugin_textdomain( 'next_page', 'WP_PLUGIN_DIR'.$lang_dir, $lang_dir );
First, you've defined the WP_PLUGIN_DIR constant, in case it doesn't exist, for backward compatibility. Next, you need to tell WordPress which directory your language files will be stored in. Finally, you've called the load_plugin_textdomain() function, which requires three arguments: the domain (as chosen when you added the gettext calls), the full path to the language directory, and path to the language directory relative to the plugin directory. The last two arguments are redundant, and again are present for backward compatibility. If you don't need your plugin to be compatible with pre-2.6 versions of WordPress, you may leave the second argument blank.
Once you've made all your localization changes, increment your plugin's version number and commit the updates. Your plugin is now ready for translators!
There is not yet an automated process by which translators can submit their work to you for inclusion in the plugin. Be sure to provide an e-mail address in the plugin's readme file so translators can send you their files. For each language, they will generate a PO (Portable Object) and MO (Machine Object) file. The .po file is human-readable; the .mo file is a compressed binary for faster loading. When you receive them, add them to the same directory where you stored your .POT file. You can then update your plugin version with the new translations.
Was this article helpful?