A large number of WordPress users are downloading non-English versions. If you aren’t thinking about localization and internationalization in your code, you should be. This course will show you how to do it the right way.
Almost 40% of WordPress downloads are for non-English, localized versions. That potentially means that if your plugin or theme is not localized, you could -- literally -- be speaking a different language than your users. This course will help to correct that; we’ll cover all of the internationalization functions, how to use them, and how to work with translators and language files to make your code fully translatable.
Chris is a freelance WordPress theme and plugin developer, one half of the design studio Arcane Palette Creative Design, lead developer of WordPress theme shop Museum Themes and Project Manager for the event management plugin Event Espresso. In his free time, he makes electronic music.
I18n from scratch Now that we know a little bit about how internationalization works, let's start working on making it happen. This module will cover the basic functions used for internationalization and what the differences are. The first concept you need to consider in internationalization is textdomains. An application can have multiple different machine objects storing text strings for different parts of the code. Textdomains allow you to break up a language file into smaller parts. In this case, defining a specific language file for a single plugin or theme. Usually, the textdomain will match the plugin slug. So, if your plugin's named My Plugin and it's in /wp-content/plugins/my-plugin and your main plugin file is my-plugin. php, probably you'll want to make your textdomain my plugin. This is more of a guideline than a rule, you can use whatever textdomain you like, but it's probably easier to remember if it's something standard that matches other elements in the plugin. The important thing to think about, when using textdomains in your plugin, is as Mark Jaquith, a core WordPress developer noted on his blog, don't get clever. For example, if you are using a predefined constant or variable in your internationalization functions for your textdomain, because you were trying to implement DRY or don't repeat yourself principles in your code, you're being too clever. PHP is a programming language and is built to understand that. But GetText is tool that understands text strings and isn't able to parse a variable in PHP. Doing so may make your language files unusable to some translators or translation programs. In fact, that's related to the first rule. Don't use variables inside a translation function's strings.
Translate all the things! In the last module I talked about how to internationalize text in WordPress. In this module we'll put it all together, and start actually doing it. The first piece is calling in the language files. The exact method by which you load a language file will depend on whether you're writing a plugin or a theme, but they are pretty similar. For plugins you do something like this. Let's wrap that in a function and hook it to an action. Let's look how this changes if we're loading a text domain for a theme. Remember earlier when we talked about loading custom language files. Load_textdomain allowed you to add additional MO files on top of the ones currently loaded. So, I'm going to add back the code to load a custom language file, if it exists. If you're doing this with a theme, we need to swap load_theme_textdomain for load_plugin_textdomain. And we couldn't use plugin_basename and would need to use get_template_directory which retrieves the path to the current theme. You might run into some issues if there was a plugin that had the same slug as the theme you were building if they were loading their custom language files in the WordPress language directory, but I'm guessing there are so few people doing this that it wouldn't be an issue for a while. You could if you wanted put it in a sub-directory like /themes if you were concerned. So instead of WP_LANG_DIR. mytheme you would use WP_LANG_DIR. themes/mytheme for your custom language files
Working With Translators Have the benefit of working with language files and translators directly, which has led me to a better understanding of how internationalization affects those actually using it. This module will cover some things that will help make your translators' lives easier. If you have looked at the code for some of the recent default WordPress themes, you may see comments like this. Here we see the developer allowing the translator to explicitly deactive the open sans font if there are characters that are used in their language that don't exist in the font. They've used the _x function to disambiguate the string, but it's still unclear what that's actually for until you read the note the developer added for translators. If the translator refers to the source code, they can see immediately what that string is for and deal with it appropriately. Translators can search the plugin or theme for any other comments directed to them by doing a search for translators and a text editor and get context for whatever special case is applied to them. This is by no means required, but it can be helpful to provide some context about a particular piece of code or a string for translation. In correlean, another theme by the automatic theme team, you can find this in the functions. php. Here we see a print f stream with percent one dollar sign s and percent two dollar sign s placeholders. A translator doesn't need to parse out the code, they just need to look at the comment. One is the date. Two is the time. You'll see it to in coral lanes pot file. If a translator is looking at the POT or the PO file in a text editor, they'd be able to see the note for them.