Speed and performance optimization are an endless tunnel. No matter where you are, there’s always room for improvement. There are the simple and trivial optimization steps and the more advanced ones. The results you’ll get are very dependent on the amount of effort you’re willing to put in.

First, it’s important to understand the basics.

When a visitors go to your site, they need to receive a response, in the form of a page.

Page Caching

Your first line of defense is page caching. Page caching will return the response from the disk, or from memory without asking WordPress to prepare it. Obviously, using page caching is the one most important step towards a fast site.

In our sites, we use either WP Super Cache or W3TC.

• WP Super Cache – easier to configure and harder to go wrong. We use that on low-traffic sites, where we just need page caching to avoid WordPress from processing each and every request.
• W3TC – a complete package for speed optimization, requiring reasonable understanding of what you’re doing. When used correctly, W3TC can perform every optimization possible for your site. However, you need to understand what you’re doing and it’s possible to crash your site when you don’t. We use W3TC on wpml.org and wp-types.com, which are relatively high-traffic sites and speed is critical. We use every single feature in W3TC to squeeze out all the performance we can.

If you’re interested in more details, check out my older, but still relevant. post about WPML and W3TC.

CDN, Minify, Object Caching and APC

Besides the basic page caching, there are a number of techniques to further improve your site’s performance. Here are the popular ones:

CDN (Content Delivery Network): Your static files will be hosted on other servers, closer to visitors. Instead of hitting your server to get static content, this content will go directly from the CDN. There are different CDN providers, such as MaxCDN and Amazon. On our sites, we use Amazon S3 + CloudFront.

Minify: Pack static CSS and Javascript files into fewer files. This way, instead of loading dozens of tiny CSS and JS files, visitors will load fewer and larger files. If you also use a CDN, this doesn’t have an effect on your server, but can greatly enhance the browsing experience by first-time visitors.

Object Cache: Stores data units that take long to compute. You can read more about that in WordPress codex.

PHP Opcode Cache: Pre-compiles PHP code, so that it doesn’t have to be interpreted from scratch for every page load.

There are plugins that implement each of these operations. W3TC implements them all too.

Specific Optimization for Your Site

Page caching, CDN and Object Caching will give your site the initial speed boost. They prevent WordPress from executing, or from executing from scratch, for every single request. However, even with all the caching in the world, sometimes, WordPress does need to produce content. Then, if it takes 40 seconds for a page to compute, it’s not going to fly.

To optimize the performance of page-rendering by WordPress, you must first understand where most of the time is spent.

I recommend to start with a plugin called Debug Queries. Enable it and look at your site’s footer. You’ll see exactly how much time PHP processing and database processing took. You’ll also get a breakdown of the individual queries that make up each page.

Debug Queries output

I cannot stress enough how important doing this is for your site. Without checking what your site does now, there’s no way to tell where there’s waste and what needs improving.

You should look for things like:

• The same query running over and over again.
• A series of queries loading individual items instead of a single query loading the entire array
• Joins on huge tables, which take long to perform
• Queries that search by columns that have no index, or text searches

All these things will surely slow your site and can be avoided. Many times, you’ll see them happening in conjunction, with a single solution to fix a few problems together.

Often, in order to really fix these issues, someone is going to have to work hard on the site’s coding. In other cases, different usage of widgets or theme options can greatly reduce the database load and increase the site’s speed.

Using WPML Better

WPML has several features that help you manage your site, but also require database resources to run.

String Translation Features

WPML’s String Translation module is fairly optimized and should not slow your site, just as long as you know what you’re telling it to do.

It already comes with a caching engine, which will load entire contexts in a single query. When  a plugin, or your theme, loads translation using a GetText call, or directly using WPML’s icl_t function, WPML will load all the translations for that context. This means that other strings that belong to that plugin or theme are already in memory. This is similar to the way GNU GetText operates.

The String Translation module includes several features which help you locate and register strings for translation. To work, they require the database. These features are not intended for normal production usage and only affect performance for logged-in users.

They are explained in the String Translation performance FAQ.

Auto ID-Adjust

WPML creates different posts for different languages. Many themes refer to specific posts and want to load them from the database. They don’t know that you’re using WPML, so they don’t care about the same page appearing on different posts for different languages.

To allow you to use your themes, without any PHP edits, WPML include a handy feature that automatically converts IDs to those in the current language. If your theme attempts to load a page in English, but the site is now displaying in French, WPML will deliver the French page instead of the English page.

To do this, WPML needs to query the database, look for the French translation and deliver this instead. This operation requires database access.

You can control how this works by enabling and disabling the feature called Adjust IDs for multilingual functionality, under WPML->Languages.

Auto ID adjustment control

For smaller and less busy sites, it might not be worth the trouble. However, for busy and performance-critical sites, we recommend to disable this option and do the ID adjustments yourself.

Use WPML’s icl_object_id function to do this manually, thereby saving many accesses on places where the ID conversion is not really required (but WPML cannot tell that). On this site, we handle ID conversion manually. It’s only needed in a handful of places.

Separate WPML’s Impact

While there are many things that you can optimize, which are not all related with WPML, we want to know that we’ve done our job right.

Grab a copy of your database and run it locally. Try with and without WPML.

If you see a huge change when you enable WPML, we want to know about it. By huge, I mean that it might take 70 queries without WPML and 900 queries with it.

You can post about your experience here, or in our technical forum (better). If we need your database dump to reproduce this situation, we’ll email you to get it privately.

These were the main challenges we faced:

• Swap the navigation, footer and other theme elements from left to right
• Adjust some fixed-position elements in the home page for proper RTL display
• Swap all floating images in posts and pages from left to right and right to left
• Display blog posts in the correct direction – we display both Hebrew or English for untranslated posts

To handle all of them, we added an rtl.css file, which loads after the theme’s CSS. This file overrides attributes for RTL display and makes the required changes for Hebrew display.

The CSS

You have 2 options for showing the correct style and layout for your RTL language:

1. Load your standard CSS and ALSO load a new CSS with only the specific changes for RTL
2. Load a new RTL CSS INSTEAD OF your standard CSS

For this site we went with option 1 and we created a rtl.css file, but you should know that if you prefer option 2, there is a really cool tool from Google called CSSJanus. This tool is a nifty python script that will read your CSS and change (almost all) the necessary values to convert your theme from LTR to RTL.

But as we did our CSS changes manually, here are the usual changes that you’ll most certainly need:

• Add direction:rtl; and text-align:right; to the body tag (or your content wrapper)
• Change all float:left; to float:right; and the other way around.
• Change all margin-left to margin-right and the other way around.
• Look for objects with position:absolute; and move accordingly.
• Look for objects with exact background-position, and move accordingly.

You get the point, but CSSJanus unit test case will give you more cases that you need to check for.

The HTML

Be sure that you have the html tag correctly coded:

<html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>

The PHP

If you proceed as we did using an extra CSS file, you can use WPML’s constant ICL_LANGUAGE_CODE to conditionally include that new CSS. In our case, the RTL language is Hebrew, so our conditional inserted just above the </head> tag in header.php look like this:

<?php if (ICL_LANGUAGE_CODE == "he"): ?>
<link rel="stylesheet" href="<?php bloginfo('stylesheet_directory'); ?>/rtl.css" type="text/css" media="screen" />
<?php endif; ?>

That alone should do it, but we have another trick for you today. In our hebrew blog we have mixed languages. Some posts are in hebrew, some in english. So we needed a way to style each post in the loop give its language. Here is where the new wpml_get_language_information API function in WPML comes handy. This is how the start of our loop in our blog index looks like now:

<?php
while (have_posts()) : the_post();
    $lang_info = wpml_get_language_information(get_the_ID());
    $direction = $lang_info["text_direction"] == 1 ? "rtl" : "ltr";
?>
    <div id="post-<?php the_ID(); ?>">

So now, each post is wrapped in a DIV with the correct class, which we can style correctly.

Have a look at this page:

http://wpml.org/documentation/getting-started-guide/language-setup/

The URL takes 68 characters.

This is the Chinese translation:

http://wpml.org/zh-hans/documentation-4/%E5%85%A5%E9%97%A8%E6%8C%87%E5%8D%97/%E8%AF%AD%E8%A8%80%E8%AE%BE%E7%BD%AE/

That’s 114 characters. A bit long for Twitter and will likely break in an email.

Sure, you can use one of many URL shortening services, but do you really need that? Do you really need to proxy your visitors through a different domain for something as simple as this?

Have a look at the bottom of every page in wpml.org. You’ll see it saying ‘short link to this page’.

The length of these links is around 22 characters. A bit less than before.

And, when you click on it, you’ll see the default link to that page. It’s not something that we invented. This is how WordPress works. Each page has an ID. When you link to that ID, you link to the page. WordPress will redirect visitors to the current permalink, so they see the nice ‘SEO friendly’ URLs.

To add to your theme, first, create a function that generates these default links. This function checks on what type of content we are and generates the URL for it.

You can copy this entire code and add it to your site’s functions.php.

function wpml_default_link($anchor){
    global $sitepress;
    $qv = false;

    if(is_single()){
        $qv = 'p=' . get_the_ID();
    }elseif(is_page()){
        $qv = 'page_id=' . get_the_ID();
    }elseif(is_tag()){
        $tag = &get_term(intval( get_query_var('tag_id') ), 'post_tag', OBJECT, 'display');
        $qv = 'tag=' . $tag->slug;
    }elseif(is_category()){
        $qv = 'cat=' . get_query_var('cat');
    }elseif(is_year()){
        $qv = 'year=' . get_query_var('year');
    }elseif(is_month()){
        $qv = 'm=' . get_query_var('year') . sprintf('%02d', get_query_var('monthnum'));
    }elseif(is_day()){
        $qv = 'm=' . get_query_var('year') . sprintf('%02d', get_query_var('monthnum')) . sprintf('%02d', get_query_var('day'));
    }elseif(is_search()){
        $qv = 's=' . get_query_var('s');
    }elseif(is_tax()){
        $qv = get_query_var('taxonomy') . '=' . get_query_var('term');
    }

    if($qv){
        $link = '<a rel="nofollow" href="' . $sitepress->language_url($sitepress->get_default_language()) . '?' . $qv . '">' . $anchor . '</a>';
    }else{
        $link = '';
    }

    return $link;
}

Next, edit your theme and call this function.

We added it to footer.php:

<?php echo(wpml_default_link(__('Short link to this page','wpml-theme'))); ?>

And, that’s all. Now, every page gets this neat short link and invites people to share it.

Go ahead, try it for yourself.

When you create a multilingual RTL / LTR site, you need to address two issues:

• Editing / translation
• Display

The first part, to create or translate your site, means working in the WordPress Admin in the right language and in the right direction. If you are translating between LTR and RTL languages, keep in mind that you’ll need to see mixed-direction content on the same screen.

When displaying the site, your theme needs to handle correct display direction for RTL and LTR languages.

This tutorial will follow our Twenty Ten Multilingual Demo Site, available in English, Spanish and Hebrew (RTL).

Preparation – Getting the Core and Theme .mo Files

WordPress itself and the default theme are fully localized into many languages. We need the most recent version of the localization, so I decided to get it from the localized WordPress builds. You can get them from here:

• http://es.wordpress.org/ – Spanish
• http://he.wordpress.org/ – Hebrew

After you download and unzip WordPress, go to wordpress/wp-content/languages. Copy the entire content to your languages directory. Do the same for the theme. The translation files will be in wp-content/themes/twentyten (or the current default theme if you’re reading this post later).

You should also configure WPML to allow it to translate the theme and plugins.

Translating

WPML’s Translation Management module allows sending jobs to translation and translating using different accounts. It also lets you translate with WPML’s Translation Editor. When mixed-direction content is involved, this is particularly important, as the Translation Editor automatically adjusts the direction for each field.

If this is new to you, first read about the Translation Management module.

This is how it looks like when I translate the Hello World post to Hebrew.

Right-to-Left Editing

You can see that the English texts are aligned to the left, while Hebrew is aligned to the right. I can even use the HTML mode to copy and paste items from English. The HTML mode displays LTR, to allow you to enter tags correctly.

When you translate strings, WPML also displays them in the correct direction. This is how the String Translation screen looks like when I translate the Search widget title.

RTL String Translation

The Translation Editor and String Translation modules will allow us to translate the site completely. Next, we see how to display it properly in the right direction.

Displaying the Site in RTL and LTR

Now that your content is translated, it’s time to move our attention to the theme.

This little line does most of the magic:

<html dir="rtl" lang="he-IL">

You can see if it you view the source of any Hebrew page. For example, the home page.

The dir=”rtl” attribute tells the site that the display direction for the entire site is Right to Left. Browsers understand it and will flip everything to right direction.

This single PHP line, from header.php, makes it happen:

<html <?php language_attributes(); ?>>

The call to language_attributes inserts the dir and lang attributes. The values come from the core .mo file. If you have the correct .mo files for WordPress, you get the correct values for these attributes.

If your theme’s HTML and CSS follow ‘safe’ practices, this is really all you need. By safe, I mean no absolute positioning or widths. If you must use absolutes, you may consider loading different CSS per language.

You can do this easily using conditional statements that examine the ICL_LANGUAGE_CODE constant (described in WPML coding API).

The Results

Here is how our demo site looks in English, Spanish and Hebrew.

English

Spanish

Hebrew

It’s not as hard as it seems. Try it and let us know how you’re doing.

The Sidebar Manager in Woo Framework is a great example for using the new Admin content-language switcher in WPML 2.3.0. It lists pages, categories and templates and lets users create special sidebars that display just for them.

Since translations are actually different pages, a sidebar that you create for a page in one language doesn’t show for its translations. This features gives the ability to create completely different sidebars per language.

You can use it to display different widgets altogether, or the same widgets but with different texts.

This video shows how I’m using it on our demo Canvas site:

I created this tutorial to show how to use the Admin content-language switcher. Many modern themes allow users to choose content for special site elements. These can be your portfolio page, items for a slider and other cool features. The Admin content-language switcher lets you choose the language of content in any Admin screen.

Widget Logic is a plugin that allows controlling where widgets display using PHP code. You can use it to specify where widgets are allowed, including which languages they will display in.

For example, supposing that I want to have different feeds in the widget area. There are different ways to do this, but I’ll show how it can be done using Widget Logic and language conditions.

Before we begin, download and activate Widget Logic:
http://wordpress.org/extend/plugins/widget-logic/

Add multiple copies of the widget to the Widget Area

Each of these widgets will be active in only one language, so we need as many copies as the number of languages we have.

The order of these copies doesn’t matter, as only one will be active at any time.

Two RSS widgets, one per language

Add language conditions per widgets

Click to edit each of these widgets and add the language conditions to the Widget Logic field.

WPML's language code

The logic that we add uses WPML’s language code constant – ICL_LANGUAGE_CODE (reference). For example, for English we add:

ICL_LANGUAGE_CODE == 'en'

This condition tells Widget Code to display this widget only on English pages.

We repeat this for all the copies that we created.

The result – different widgets per language

You should expect to see the different widgets per language now.

English page	German page

If you’re not familiar with it, W3TC is a site-performance plugin. It includes page cache but that’s just the beginning. Beyond the basic page caching, it also minifies JS and CSS files, compresses everything and runs a CDN (content delivery network). Put together, these functions can speed up a site by a huge factor, allowing complex WordPress sites to cope with high-volume traffic.

Why it’s so important for WordPress sites?

A picture is worth a thousand words. This is how our site loads without any caching (generated by Pingdom Tools):

WPML.org load time without any caching > 30 seconds

If you think that this is scary, keep in mind that in reality is was worse. This loading time chart was taken when our server is actually running on 5% load. When it really ran without a cache, the server was cooking at 95% load and processing time was much longer. The first byte took 5 seconds to come out and not 1/2 second like you see in this chart.

To fully display our home-page, our server had to send 77 files. Even this chart, running at 5% server load, ends with a timeout at 30 seconds (see the red lines).

Is it because of sloppy programming and bad design practices? No.

The power of WordPress comes from the modularity. You can choose any theme you like, with any combination of plugins. It means that each of these is developed independently and runs with its own resources. Most plugins that you enable include several CSS and Javascript files and contribute to the PHP and MySQL processing efforts. You could optimize it manually, but then you’d lose all this great modularity and we’re back to square zero.

Run your site through Pingdom’s tools, or other page-load time measurement (there’s a Firefox add-on for it). See which files load and their order. You’ll notice that CSS files load images and other CSS and that there are heaps of Javascript files loaded for each page.

To get your appetite going, here’s what we achieved using all the bells and whistles from W3TC:

WPML.org page load time with full caching, minify and CDN < 2 seconds

The numbers you’re seeing here are correct. A total of 28 files are fetched to display the page. 5 files come from wpml.org (our own server) and the rest come from the CDN (content delivery network). PHP barely needs to do anything to serve this page, except check that it’s in the cache and a few other tiny checks.

The entire page loads in less than 2 seconds and causes load that we can hardly measure on the server. We’re happy, visitors are happy and even Google is happy.

Step 1) Page Cache

The first and most basic thing you’d want to do is enable page caching. Go to Performance, enable W3TC and configure the Page Caching section.

Page-caching settings

For page caching, we stayed with the basic settings. One thing that we added was to exclude the client account and download sections from the page cache, so that W3TC doesn’t interfere with WPML client accounts and WPML downloads.

If you’re using an opcode cache, W3TC will take advantage of this to further speed your site. We’re not using it, but it’s worthwhile if you’re running complex PHP processing that’s not cached.

Step 2) Minify – pack and compress CSS and Javascript

Remember all those CSS and JS files that the theme and plugins add? Now is the time to fix the load they’re causing.

Minify collects multiple resource files, packs them into a single file and compresses it. The result is one larger file instead of dozens of tiny ones.

Even though the total size may shrink by only 50%, the load that this saves is huge. Instead of the browser having to issue multiple HTTP requests and get many tiny files, it issues a single request and gets them all together. This change is probably the biggest contributor to improving your site’s responsiveness – especially to new visitors (who don’t have your CSS and JS cached already).

Click on the Help button at the top of the page. W3TC will run through your entire site and look for resource files. Then, it lets you choose which to combine. Normally, you can select all, but you need to pay some attention to what you’re doing, as this can change the loading order.

Once you’ve selected the CSS and JS files to minify, you need to make sure that their order is correct.

For CSS files, drag files up and down in the list.

W3TC CSS Minify list

The order you see in this list should match the order in which CSS files are loaded without Minify. You can see that in your HTML page source.

Javascript files are a little trickier. Here, the loading order is even more critical as the wrong order will result in JS errors and broken functionality.

W3TC Javascript Minify

W3TC lets you choose which JS files go to the header section and which go to the body. For example, the Google Analytics scripts would go just before , which jQuery goes into the header, as it needs to run first (and outside of the minify list).

Step 3) Content Delivery Network (CDN)

For us, the icing on the cake comes in the form of a beautifully functional CDN.

Configuring and running a CDN is beyond the scope of this post, as it requires setting up and account in a 3rd party service.

For our own sites, we using Amazon S3 for storage and CloudFront for delivery. There are other fine options out there which you can explore and compare.

Once your CDN account is set up, W3TC sends your local files to the CDN and replaces links from your server to the files in the CDN. Then, your server only sends the HTML files and the CDN takes care of the rest.

While your server is a single machine, the CDN is actually a network of servers. It will send the files from the closest server to each visitor. CDNs can serve static files much faster than any single server can. By using a CDN, you improve your visitors’ experience and drastically reduce your server’s bandwidth and network utilization.

W3TC CDN settings

You should follow the CDN setup wizard in W3TC. It will help you transfer the media library, theme and plugin resources to the CDN.

Having fun with site performance optimization? Let us know by leaving a comment here!

We’ve talked about it before, but I think that we never really gave a comprehensive guide about translating themes and plugins. Here goes.

Translation Languages

First, let’s talk a minute about which languages you’re translating between.

If the default language of your site is English, you can just skip this section. Otherwise, please pay full attention – this is important stuff.

Your theme and plugins needs to be translated from English. Even if the default language for your site is Spanish (for example) and you’re translating only to Portuguese (yet, another example), English is involved too.

The original language of almost all themes and surely all plugins is English. If you’re using .mo files, they would include translation from English to both Spanish and Portuguese. Yup, although you don’t have English anywhere in your site’s contents, it still appears in many places, so you actually need to translate from English to your languages.

Normally, folks don’t need to worry too much about it, because they just download .mo files. So, why are we making a big deal of it?

Because WPML’s String Localization mechanism works exactly like GetText. It will translate everything from English to other languages. This means that if you’re using it also to translate admin texts, these texts need to be in English. We’ve talked about this a bit (with an example) in this blog post.

How to Translate

Now that we understand which languages to use, we need to start translating.

WPML gives you two options for translating strings. You can either use the GetText .mo files or use WPML’s String Translation mechanism.

These two solutions are functionally very similar. There’s also no performance difference. The only difference is the process you’re using.

Have a look at our theme localization guide. It shows exactly where to click and what to do to scan your theme and plugins.

Translating With WPML’s String Translation

WPML’s String Translation editor allows you to enter translations for each string in each language. It’s a simple editor, with search functionality. This interface is convenient if you’re translating for yourself, or if your translators already have WordPress user accounts.

In case you’re using our professional translation, your translators don’t need to touch the String Translation editor or log in to WordPress. Just click on the button to send the strings to your translators and you’re done.

Translating Using .mo Files

MO files are like dictionaries, telling how to translate strings from on language to another. You would need to have as many MO files as your site’s languages.

The process of translating with MO files goes like this:

1. Create a POT file with the strings to translate. There are many tools for that. WPML includes a robust PHP scanner and can produce these POT files for you.
2. Send the POT files to your translators. You might want to know that ICanLocalize also provides translation service for PO / POT files. You’re also welcome to learn more about it in the tutorial on translating PO and POT files.
3. Get the PO and MO files from the translators and upload to your site. Each translator should return at least a PO (Portable Object) file. The PO file is the text version of the translation. From that, you can create a MO (Machine Object) file.

How is it Working for You?

Leave a comment and tell what you’re doing for theme and plugins localization!

But, with great power comes great responsibility. WordPress 3.0 is a major change from previous versions. True, it uses the same tables, but a lot of the API has changed. This can cause existing plugins and your theme to go wild.

I’d like to tell about what we did to make sure everything runs smooth after the migration.

Migrating to WordPress 3.0

1. Backup

First, you should do a complete backup. I just zipped everything from the wordpress directory (including WordPress core itself). Then, created a database backup.

You can make selective file backup as well, but a few more MB of backup are not going to hurt anyone and its way easier to use, should anything go wrong.

2. Create a test site

Going from WordPress 2.9.0 to 2.9.2 is pretty safe, but the jump to WordPress 3.0 calls for a staging site.

Create a new test site and unzip the files backup you made before.

Next, you need to copy the database.

For this, you can’t just copy. You need to edit the SQL dump. Open any text editor and do a global replace for the site’s domain. Supposing your live site is www.justgreat.com and your staging site is dev.justgreat.com, replace all:

www.justgreat.com -> dev.justgreat.com

This SQL dump replacement means that everything in the staging site goes to the correct URL. Now, you can apply the database.

3. Check that your test site is good

So far, we haven’t done much. We just have a full copy of our live site where we can test on. Check that it works correctly and we’ll move on.

4. Update to WordPress 3.0

And, we’re ready. Now, get the latest WordPress nightly build. Unzip it over your current version in the staging site.

Log in to the WordPress Admin. The first thing you’ll see if that WordPress suggests to update the database.

And, you’re done. Now, you’re seeing how your site looks like in WordPress 3.0.

Is it working?

GetText is a GNU’s text localization package. It allows replacing text in one language with texts in another language.

We’ve already talked about using GetText to build multilingual themes. Now, we’ll talk about how to make the theme’s texts translatable, from the translator’s point of view.

Complete sentences only, please

Translators cannot accurately translate single words. They need to see the entire sentence in order to translate correctly.

For example, what does You must be mean?

In English, the word be has one meaning. But, in Spanish, be mean what you are (ser) or where you are (estar). There’s no way a translator can translate this correctly without seeing the entire sentence.

This is the code that’s responsible for the text:

<?php _e('You must be') ?> <a href="<?php echo get_option('siteurl'); ?>/wp-login.php?redirect_to=<?php echo urlencode(get_permalink()); ?>"><?php _e('logged in') ?></a> <?php _e('to post a comment.') ?>

So, what do we do?

Using full sentences with placeholders

What we’ve actually done in this example is concatenate several parts into a sentence. The way we did it broke the sentence into different pieces, losing all meaning in the process.

Here is this same thing, built with a single sentence a placeholder:

<?php printf(__( 'You must be <a%s>logged in</a> to post a comment' ), ' href="'.get_option('siteurl') . '/wp-login.php?redirect_to=' . urlencode(get_permalink()) . '"') ?>

What we’ve done is:

1. Create one large text that includes a placeholder.
2. Use printf to replace the placeholder with an actual value.

The translator now needs to translate this sentence:

You must be logged in to post a comment

The translator can easily translate this entire sentence.  No questions to ask and no problems translating!

Besides being easier to translate, we need to remember that in different languages words appear in different order. Supplying the complete sentence with placeholders will allow the translator to flip the order of words and produce grammatically correct (and sensible) transaltions.

Really advanced case (appears in every WP site)

Look at this PHP code. It appears in almost every WordPress site in the comments section.
<h3><?php comments_number(__('No Responses'), __('One Response'), __('% Responses') );?>
<?php _e('to') ?> &#8220;<?php the_title(); ?>&#8221;</h3>

The translator would have to translate the word to. But, it’s impossible without understanding how to is used in the sentence.

The word to is part of a sentence, which would be:

3 Responses to new widgets

Once the translator sees the entire sentence, it all becomes clear and easy to translate.

To turn this into a single sentence, we’ll use this PHP code:
<h3><?php printf(__('%s to %s'),
get_comments_number_ml(__('No Responses'), __('One Response'), __('% responses') ),
'&#8220;' . get_the_title() . '&#8221;')?></h3>

This code produces a full sentence to translate. Now, the translator can produce correct translation to your comments heading.

Note: we’ve replaced the standard WP get_comments_number with an identical function that returns the comment count as a value and doesn’t echo to the screen. You can download this PHP code from get_comments_number_ml.zip.

What about your themes?

Are your multilingual themes built for correct translation?

An easy way to test is to open your .po file in poedit and review the strings. If you’re seeing anything that isn’t clear by itself, look for it in the source and revise.