class My_Plugin {

    public function __construct()
    {
        load_plugin_textdomain('my-plugin', FALSE, dirname(plugin_basename(__FILE__)).'/languages/');
    }
}

$my_plugin = new My_Plugin;

As soon as the plugin file is loaded, the plugin constructor will be triggered. In there, load_plugin_textdomain() is called and gets told to load the applicable mo-files from the subdirectory “languages” of the plugin’s directory. That looks fine. You just drop your translation files in that directory and everybody is happy. Then the plugin gets updated and your custom translation is deleted. Ouch! Clearly, putting your own language files somewhere in the plugin’s directory is not a good idea.

A look at the source of the load_plugin_textdomain() function shows that after building the path to the mo-file, it simply calls the more general load_textdomain() function. That functions provides some useful hooks you can use to load your custom translation files without having to touch the plugin code.

Call load_plugin_textdomain() during init

The plugin setup shown above has one big problem, though. By the time you want to hook into the load_textdomain() function, in your theme’s functions.php file for example, it will be too late already since the load_plugin_textdomain() call gets done immediately when the plugin is loaded. That is why when developing a plugin you should call load_plugin_textdomain() during the init action and not earlier. Let’s fix that.

class My_Plugin {

    public function __construct()
    {
        add_action('init', array($this, 'load_plugin_textdomain'));
    }

    public function load_plugin_textdomain()
    {
        load_plugin_textdomain('my-plugin', FALSE, dirname(plugin_basename(__FILE__)).'/languages/');
    }
}

Now you have the chance to hook into load_textdomain(). Before we get there, it is worth noting that function calls for translatable strings, like __() or _e(), executed before the language files are loaded will be useless, as shown below. Be sure to bind the whole plugin initialisation to the init action to prevent this problem.

public function __construct()
{
    add_action('init', array($this, 'load_plugin_textdomain'));
    $text = __('I will not be translated!', 'my-plugin');
}

load_textdomain() hooks

Back to load_textdomain(). This functions provides three useful hooks, all of which get passed the language domain and path to the mo-file as arguments, albeit in different orders.

Filter: override_load_textdomain

This filter allows you to block the loading of a certain language file by returning TRUE. Even though this is not what we are looking for now, here is a quick example to block any language file that would get loaded from the plugin’s own “languages” directory. This code could go in your theme’s functions.php file.

add_filter('override_load_textdomain', 'block_my_plugin_default_language_files', 10, 3);

function block_my_plugin_default_language_files($override, $domain, $mofile)
{
    if ('my-plugin' === $domain && plugin_dir_path($mofile) === WP_PLUGIN_DIR.'/my-plugin/languages/')
        return TRUE;

    return $override;
}

Filter: load_textdomain_mofile

This filter allows you to change the path of the mo-file to load. This means that the original mo-file will not be loaded anymore. You basically replace the language file of the plugin with your own. This is a viable option, yet having the plugin’s default language file as a fallback is often a more preferable setup.

add_filter('load_textdomain_mofile', 'replace_my_plugin_default_language_files', 10, 2);

function replace_my_plugin_default_language_files($mofile, $domain)
{
    if ('my-plugin' === $domain)
        return WP_LANG_DIR.'/my-plugin/'.$domain.'-'.get_locale().'.mo';

    return $mofile;
}

Action: load_textdomain

This action looks like your best option. It allows you to load one or more additional language files on top of the plugin’s language files. The default language files of the plugin will be loaded after yours.

add_action('load_textdomain', 'load_custom_language_files_for_my_plugin', 10, 2);

function load_custom_language_files_for_my_plugin($domain, $mofile)
{
    // Note: the plugin directory check is needed to prevent endless function nesting
    // since the new load_textdomain() call will apply the same hooks again.
    if ('my-plugin' === $domain && plugin_dir_path($mofile) === WP_PLUGIN_DIR.'/my-plugin/languages/')
    {
        load_textdomain('my-plugin', WP_LANG_DIR.'/my-plugin/'.$domain.'-'.get_locale().'.mo');
    }
}

Load from the WordPress languages directory by default

The load_textdomain() functions allows for a lot of flexibility. Yet as a plugin developer you can make it even easier for the people using your plugin. By default you could look in the WordPress languages directory for translations of your plugin. That way custom translations would only need to be dropped in the subdirectory by the name of your plugin, in the WordPress languages directory. No need for the user to attach to any hooks in the code, and no problems during a plugin update.

Note that the default WordPress languages directory is “wp-content/languages/” but it can be overridden in wp-config.php by defining WP_LANG_DIR yourself.

public function load_plugin_textdomain()
{
    $domain = 'my-plugin';
    // The "plugin_locale" filter is also used in load_plugin_textdomain()
    $locale = apply_filters('plugin_locale', get_locale(), $domain);

    load_textdomain($domain, WP_LANG_DIR.'/my-plugin/'.$domain.'-'.$locale.'.mo');
    load_plugin_textdomain($domain, FALSE, dirname(plugin_basename(__FILE__)).'/languages/');
}

Finally, I would like to point out that is important to load custom user language files from WP_LANG_DIR before you load the language files that ship with the plugin. When multiple mo-files are loaded for the same domain, the first found translation will be used. This way the language files provided by the plugin will serve as a fallback for strings not translated by the user.

All in all by following a few practical guidelines you can make the loading of translations for your plugin a joy instead of a frustration.

Some well-known techniques to reduce HTTP requests include using CSS sprites and combining multiple scripts and stylesheets into single files. Ideally you should be using only one stylesheet. However, how many times have you seen the following two lines in the <head> of a HTML page?

<link rel="stylesheet" type="text/css" href="screen.css" media="screen" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

Combining screen and print styles

I get the impression many people are unaware of the fact you can combine screen and print styles into a single stylesheet. Actually you can combine all media types, and it is easy to do.

Linking to your stylesheet

<link rel="stylesheet" type="text/css" href="styles.css" media="screen, print" />

You may be wondering why I did not use media="all" or simply omitted the media attribute. By stating the media types the stylesheet applies to right there in the <link>, user agents may decide not to load the stylesheet at all if it does not apply to the current device. Another possible HTTP request less.

Splitting up your stylesheet

All that is left to do is telling the browser which parts of styles.css apply to screen and which parts apply to print. The example below is self-explanatory.

@media screen {
	body { font-size:14px; }
}

@media print {
	body { font-size:10pt; }
	h1, h2, h3 { page-break-after:avoid; }
}

Styles that apply to both screen and print do not need not be wrapped in an @media rule in this case since the stylesheet itself applies to both media types already, as specified in the <link>. Just for the sake of completeness, though, note that you can specify multiple media types separated by commas.

@media screen, print {
	body { line-height:1.4; }
}

To freshen up your knowledge about @media rules, I recommend you have a look at the CSS specification for media types.

Codebench goals

Benchmark multiple regular expressions at once

Being able to compare the speed of an arbitrary amount of regular expressions would be tremendously useful. In case you are wondering – yes, I had been writing down benchmark times for each regex, uncommenting them one by one. You get the idea. Those days should be gone forever now.

Benchmark multiple subjects at once

What gets overlooked too often when testing and optimizing regular expressions is the fact that speed can vastly differ depending on the subjects, also known as input or target strings. Just because your regular expression matches, say, a valid email address quickly, does not necessarily mean it will quickly realize when an invalid email is provided. I plan to write a follow-up article with hands-on regex examples to demonstrate this point. Anyway, Codebench allows you to create an array of subjects which will be passed to each benchmark.

Make it flexible enough to work for all PCRE functions

Initially I named the module “Regexbench”. I quickly realized, though, it would be flexible enough to benchmark all kinds of PHP code, hence the change to “Codebench”. While tools specifically built to help profiling PCRE functions, like preg_match or preg_replace, definitely have their use, more flexibility was needed here. You should be able to compare all kinds of constructions like combinations of PCRE functions and native PHP string functions.

Create clean and portable benchmark cases

Throwing valuable benchmark data away every time I needed to optimize another regular expression had to stop. A clean file containing the complete set of all regex variations to compare, together with the set of subjects to test them against, would be more than welcome. Moreover, it would be easy to exchange benchmark cases with others.

Visualize the benchmarks

Obviously providing a visual representation of the benchmark results, via simple graphs, would make interpreting them easier. Having not to think about Internet Explorer for once, made writing CSS a whole lot more easy and fun. It resulted in some fine graphs which are fully resizable.

Below are two screenshots of Codebench in action. Valid_Color is a class made for benchmarking different ways to validate hexadecimal HTML color values, e.g. #FFF. If you are interested in the story behind the actual regular expressions, take a look at this topic in the Kohana forums.

Benchmarking seven ways to validate HTML color values

Collapsable results per subject for each method

Working with Codebench

Download Codebench at GitHub. Since Codebench is a module for the Kohana PHP framework, I suggest you install Kohana first if you have not already done so. Add Codebench to the list of activated modules in application/config.php.

Creating your own benchmarks is just a matter of creating a library that extends the Codebench class. Put the code parts you want to compare into separate methods. Be sure to prefix those methods with “bench”, other methods will not be benchmarked. Glance at Valid_Color.php in the download for a real example.

Here is another short example with some extra explanations.

// libraries/Ltrim_Digits.php
class Ltrim_Digits extends Codebench {

    // Some optional explanatory comments about the benchmark file.
    // HTML allowed. URLs will be converted to links automatically.
    public $description = 'Trimming leading digits: regex vs ltrim.';

    // How many times to execute each method per subject.
    // Total loops = loops * number of methods * number of subjects
    public $loops = 100000;

    // The subjects to supply iteratively to your benchmark methods.
    public $subjects = array
    (
        '123digits',
        'no-digits',
    );

    public function bench_regex($subject)
    {
        return preg_replace('/^\d+/', '', $subject);
    }

    public function bench_ltrim($subject)
    {
        return ltrim($subject, '0..9');
    }
}

And the winner is… ltrim. Happy benchmarking!