WordPress 3.9.1 and 3.9.2 almost to the point • WordPress Help

It is quite likely that the update to WordPress 3.9.1 will be available this Wednesday, and a few days later to version 3.9.2 .

According to reports Nacin on the development blog these versions will be maintenance, solving flaws detected since the release of WordPress 3.9 .

That at the moment, but if you find something else you know, inform so that arrange, that's the greatness of open source communities.

Oh, and remember that these updates will be automatic, without your intervention, unless you have disabled them .

Prepare WordPress plugins for translation • WordPress Help

Some time ago we saw how prepare WordPress themes for translation but also plugins gain more popularity, and ultimately They are more useful for all types of users if they are prepared for translation. In such a globalized world, it does not make sense to restrict the popularity of a plugin to only the language of a few, no matter how many? .

The process, similar in some aspects, to that of the topics, passes through a good series of steps that add task to the definitive publication of the plugin but that, without a doubt, will make your plugin add many points in favor of the WordPress user community .

Internationalization vs. localization

Before you can internationalize your plugin you should know what this means. Also known as i18n it means modifying the plugin so people from other languages ​​can easily use your plugin.

Localization is the pure and hard process of modifying the plugin to another language. However, internationalizing entails much more than simply translating the plugin's interface. For example, use of metric system or Anglo-Saxon units, punctuation marks to separate thousands, and all those particularities.

Although the following guide is location-oriented do not forget those additional factors, to take them into account.

Domains and initialization

Locating your plugin means that you have to have a text domain, keeping each separate from the rest that WordPress or other plugins use. It does not matter what you want to use as a text domain but choose something unique, if possible that is related to your plugin.

Before locating your plugin completely you will have to tell WordPress how you can find your text strings. If the code does not exist you will have to insert something like this:

This code communicates with WordPress and tells it to use the function called myFunction when it loads. Then, this function will give WordPress the name of your text domain and will teach you how to load the localized text strings, something like this:

The WordPress function load_plugin_textdomain informs WordPress that there is a text domain called mydomaintext and that the files that have the localized strings are in the server folder wp-content / plugins / miplugin . Of course, the conventions used in this article should be changed by your folder path, text domain name, function name, etc, I think you already imagined it but it never hurts to remember it.

Preparing the chains

After initialization you will have to change the static strings for a function that allows WordPress to use the appropriate localized version of that string. More than anything for WordPress not to use the wrong language.

This function offers a short name that facilitates internationalization: the function with double low bar __ (string, domain) . The function has two parameters, the first is the string that the plugin uses by default if there is no localized version available, and the second parameter is the same text domain that you chose in the previous code.

Before we get this step our code would be like this:

And then it would be in this way:

Location

Once all the previous preparations have been made, you will be ready for the actual process of making your WordPress plugin available in several languages.

Creating a location for your plugin requires making a file ] .po with name similar to the file of your plugin, and with the ISO 639 codes of two letters for each country and language. For example, if your plugin is called "miplugin" and you want to locate it in Spanish of Spain it would have to be called the file: "miplugin-es_ES.po"

Although the WordPress codex offers tools that can help localization often it is better to simply pull the file .po from another plugin as a base. The files .po are made with a simple header and then the translation pairs:

The msgid is the standard string that appears in the function double low bar that you defined. Once created the file .po you can use any tool to create the files .mo which is the other file that WordPress requires for the translation, and actually the only one that will read for do it Personally, I recommend you use PoEdit which is also cross-platform.

Let other translators help

Nobody knows all the languages, at least nobody I know, so if you want to expand the popularity of your plugin the best thing is to increase your resources and allow others to translate your plugin.

Now, this requires a special procedure to generate the necessary files to offer the translators, since you will not pass them the source code so that, by mistake, break something they should not, right? That being a translator does not mean that they are also programmers.

The files that you will have to give to the translators is a file POT which is more or less like this:

There are two ways to create this file. If you have already uploaded your plugin to the repository, go to the administration page and choose "Generate POT file". This file is the one that you will send to the translators to translate the plugin. If you want, sometimes it's a good idea to also send them the full plugin in case they have doubts about where everything is going, so they can install it and see the changes after the translation.

If you do not have the plugin in the repository yet you can go to the WordPress i18n tools directory and use the makepot.php script like this: