Tag Archives: translating

Translating Strings In WordPress Containing Multiple Placeholders

Posted on by

I really often see a common mistake made when translating strings in WordPress so I thought I’d write a blog post in order to shed more light on the issue.

But first, here’s a quick refresher on how to internationalize code in WordPress:

<?php _e( 'Welcome to my blog!', 'my-plugin-text-domain' ); ?>

For dynamic strings, it’d be something like this:

<?php printf(
	__( 'Welcome to my blog, %s!', 'my-plugin-text-domain' ),
	$name
); ?>

But what about when you have multiple variables to use in your string? A common mistake is to do something like this:

<?php printf(
	__( 'Welcome to my blog, %s! Today\'s date is %s.', 'my-plugin-text-domain' ),
	$name,
	$date
); ?>

The issue with this is that you’re requiring the person’s name to always come before the date. If for internationalization reasons it needs to be in a different order, then it won’t work. You’ll end up with something like Today's date is Alex. Welcome to my blog, November 2nd!.

The solution is to use standard sprintf() argument swapping parameters:

<?php printf(
	__( 'Welcome to my blog, %1$s! Today\'s date is %2$s.', 'my-plugin-text-domain' ),
	$name,
	$date
); ?>

Now translators are free to re-order the string to whatever makes the most sense for the language in question without having to worry the order of the variables.

For a more in-depth review of this, check out the WordPress Codex where many real world examples can be found.

Translating WordPress Plugin Details

Posted on by

Plugin authors: did you know that you can allow translators to localize the plugin details that show up in the plugins list in the WordPress administration area? Your plugin’s name, description, and so forth? Well you can! It’s actually really simple to do and all you need to do is add one or two additional plugin headers to your file.

The first is Text Domain and this is the text domain for your plugin, i.e. the first argument that you are passing to load_plugin_textdomain().

The second one is Domain Path and is optional. It’s only needed if you store your translation files in a subfolder inside of your plugin’s folder.

Here’s an example load_plugin_textdomain() call from one of my newest plugins:

load_plugin_textdomain(
	'add-descendants-as-submenu-items',
	false,
	dirname( plugin_basename( __FILE__ ) ) . '/localization/'
);

That loads translation files from a subfolder called “localization” inside of my plugin’s folder. This turns into the following plugin header:

Plugin Name:   Add Descendants As Submenu Items
Plugin URI:    http://www.viper007bond.com/wordpress-plugins/add-descendants-as-submenu-items/
Description:   Automatically all of a nav menu item's descendants as submenu items. Designed for pages but will work with any hierarchical post type or taxonomy.
Version:       1.1.0
Author:        Alex Mills (Viper007Bond)
Author URI:    http://www.viper007bond.com/

Text Domain:   add-descendants-as-submenu-items
Domain Path:   /localization/

An extra line break isn’t needed nor is the extra spacing but I added both just for aesthetic reasons.

And that’s it! WordPress will then attempt to translate the plugin’s name, URI, description, author, author URI, and version fields. I personally only include the plugin’s name and description in my translation template files though as I don’t feel translators need to localize the other fields.

If you need help generating a translation template file for your plugin, log into WordPress.org and then visit the “Admin” tab on your plugin’s page on WordPress.org. You can generate a POT file for your plugin there.