Version française disponible

This is not a native feature of WordPress, fortunately, a free plugin qTranslate is existing. Unfortunately, the plugin activation only will not make everything and you will have to go further than that.

User reviews on qTranslate are quite mixed. When installing the plugin, most users hope to have nothing (or almost nothing) to configure. Then, they often complain when they realize that it does not work as they would expect (and give a bad score).

WordPress is constantly evolving with thousands of plugins available. Thus, it is impossible to achieve the perfect multilingual plugin that can handle everything through a single interface, and all of that without a single compatibility issue. It would be a dream, and I remind you that qTranslate is free…

Multilingual theme & plugins or nothing

First, if your theme does not support multiple languages (i.e. includes several language files and supporting the transition from one to another), it is not even needed to go further. You have two choices:

• Either change your theme with a newer one that manages it
• Either make your theme multilingual (in case it is your own theme, you should know how to do and go back into your code will not be that hard).

Also, if you use dozens of “exotic” plugins, there is a good chance that you will have some compatibility issues with qTranslate. I suggest you limit your site to fifteen plugins that are widely used. This is particularly true for the essential ones. By essential, I mean that your site cannot work correctly if you disable them.

A famous plugin with a good rating (it normally goes hand in hand) will ensure that:

• It is followed (bugfixes and updates available when there is new version of WordPress)
• You have some support (there is probably a user who had the same problem as you before)
• It is multilingual. Making a multilingual plugin is possible, but if you can avoid this, that’s better!

You can consult the list of plugins that I use on my own site. They are all working with qTranslate, are known and have good ratings for the most part.

If your theme and your plugins are multilingual, you will see that when switching of language, the whole system will be affected. For example, the Jetpack configuration interface or the WordPress administration dashboard will adapt…

Translation management from the WordPress dashboard

Post management is well integrated with qTranslate. You have as many fields as you have activated languages for both fields: title and content of each post. This is the same with category and tag sections.
qTranslate allows you to enable as many languages as you want. In my case, I enabled English and French. There are two languages so all translatable fields are duplicated.

Edit a post with qTranslate enabled

While most information is translated automatically, this is not the case for all existing information that I had to fill in at the creation of the blog.
I can use a tag provided by qTranslate to add my own translations, for example [:code_lang_1]My text in language 1[:code_lang_2]My text in language 2.

For example, here is the new value for the site tagline that appears at the top:

Change the tagline depending on the language

Similarly, you have to change as much as possible all titles, descriptions… all the texts appearing on the site but not translated yet. Here is a non-exhaustive list (will mainly depend on your plugins):

• The site tagline
• The title of some widgets
• The description of each site links
• The line about the author on RSS post feed (WordPress SEO)
• The text used in the views counter (WP-PostViews)
• The text used in the page navigation (previous page, next, last…) (WP-PageNavi)
• Title and default text for the related posts (Yet Another Related Posts Plugin – YARPP)

If you use the Contact Form 7 plugin, don’t forget to create as many contact forms as your site supports different languages.

Advanced translation management (source code)

You have done all possible changes and little tweaks from the administration interface, but you realize that there are still a few things to improve to make your site completely multilingual.
In this case, there is no other choice but to dive into the PHP code and manually edit some files of WordPress, your theme or even some plugins. For example:

• Include the language code when building the RSS feed links
• Adding qTranslate language selector in the header of the theme
• Display different images in the theme according to the language
• Make plugins aware of the current language selected. Plugins such as Shadowbox, List category posts, WordPress SEO, Disqus, Social media icons…

For this last part, there is no secret, you must change the code by yourself and call new functions available when qTranslate is enabled.
Here is a code snippet to retrieve the language and set the text as appropriate.

if(function_exists('qtrans_getLanguage')) {
	$lang = qtrans_getLanguage();
	if ($lang == 'en')
		$text = 'english';
	else
		$text = 'french';
}

Be careful when you make some change to the code, be aware that an update will overwrite all your changes. So make sure to note ALL the changes you have done before updating WordPress, your theme or a plugin. If it becomes too difficult to maintain, it is a good idea to think about a system that integrates automatically your changes after an update. It’s up to you!

In many cases, you have certainly understood that you will need to go deeper and modify the source code of the incompatible plugins. This is needed to solve problems, but also to add some polish after a language switch in order to build the best user experience.

Over time, I guess you will finally realize that the hardest and tedious part is not to make a multilingual site, but to translate all your articles in all the languages you are supporting!

 Version française disponible

Not so long ago, I was talking about the “Mobile theme” feature included in the Jetpack plugin to ensure that your WordPress blog is accessible on mobile devices by making its content legible.

I will not change my mind about this great plugin because it works very well and each new version of Jetpack brings lots of improvements. Also, the fact that there is nothing to configure, just a button to activate the theme is a big advantage, you can hardly do better. Yes, but… if you are not scared of doing some programming, there is something even better!

I’m talking about Responsive Web Design, a very trendy concept that is not going to fade away. With Responsive Web Design, the site is unified on all platforms and automatically adapts to the screen size. The identity of your site remains the same (theme, images, colors…) and it saves you from maintaining different versions: desktop, mobile, tablet… The management of your site is simplified and its maintenance becomes much easier.

Before, there were few screen resolutions available (usually people were using a 1024 x 768 resolution or, for the lucky ones, a 1280 x 1024 resolution), it was the time of the 17 and 19 inch CRT monitors (ouch, my eyes are hurting… ok I am talking about ancient history). Today, there are hundreds of different sizes and resolutions on the market, Internet is everywhere on your TV, in your car or even in your fridge (well I guess I see a little bit too far, but this all-connected world is maybe not so far). In short, it is no longer possible to work on fixed resolutions on a case by case basis.

Of course, in the case of a specific application, there are arguments against the Responsive Design. A web application will have slower performance compared to a native app. But it is not the point here. I want to focus on general websites with a broad target audience (a newspaper, an online shop…). These websites need to be available on mobile devices and they should avoid using dedicated mobile versions (I am talking about the famous URL beginning with “m”). For instance m.facebook.com, m.linkedin.com or m.lequipe.fr which will disappear sooner or later.

Test by yourself

Right now, you can change the size of your browser window, you will see that this blog will automatically adapt (if you see bugs or have any idea for improvement, let me know!)

CarmaBlog in 1024 x 768

CarmaBlog in 400 x 768

You have probably noticed it, there are different changes as the width of the window decreases:

• The main menu becomes smaller before being replaced by a drop-down list.
• Some blocks are moving on a new line (RSS icon and search box).
• The secondary content disappears in favor of the principal. On a small screen, we want to get to the point (articles in my case) and avoid too much scrolling.
• The shadow effect and the background disappear. On small screens, dozens of pixels can represent 10% of the whole size, you have to take care of that.
• Images are resizing dynamically to avoid excessive disproportions.

Plenty of Responsive frameworks…

Many frameworks exist to help you achieve a responsive site. The best known is probably Bootstrap, by the way that’s the only one I already used on a project. There are plenty of others:

• Foundation
• Gumby
• Unsemantic
• Skeleton
• Pure
• KnaCSS

Home-made Responsive

It is also possible to make Responsive Web Design by yourself, without any framework. Actually, my blog is a good example. Some code of CSS, some code of Javascript and a few hours of work, that’s what you need. The final result may be not compatible with IE6, it certainly does not show great and smooth animations, but it will be more than enough in most cases.

The secret is to use media queries available from CSS3, below are some code samples:

@media all and (max-width:1000px) {
	.sidebar div {
		display:none;
	}
}

If screen width is less than 1000 pixels, the right and left sidebars are hidden.

@media all and (min-width:870px) and (max-width:975px) {
	#menu ul li {
		font-size:.7em;
	}
	#header_image {
		height:150px;
	}
}

If screen width is between 870 pixels and 975 pixels, the header and the menu are smaller.

@media all and (max-width:870px) {
	#menu {
		display:none;
	}
	#menuselect select {
		display:block;
	}
	#header_image {
		height:80px;
	}
}

If screen width is less than 870 pixels, the menu is replaced by a drop-down list. The header image is shrunk a second time.

@media all and (max-width:585px) {
	img:not(.fixed):not(.avatar):not(.wp-smiley):not(#sb-player) {
		height:auto !important;
		max-width:80%;
		min-width:70px;
	}
}

If screen width is less than 585 pixels, images are minimized. Images with CSS classes “wp-smiley”, “fixed”, “avatar” or with the ID “sb-player” are not affected. I had to do that because I had the problem of having some icons like smileys getting magnified, also some strange behavior with the embedded slideshow of Shadowbox.js player… I also add a restriction on the height (because I think you need a good view to see the content of an image smaller than 70 pixels).

Note: I use the “!important” keyword to redefine a style already present. The value specified with the “!important” will always overwrite the others.

I also wrote some Javascript to create the drop-down list that replaces the menu. I do not show the code here (it is very specific to my site), but be aware that the function have no more than 15 lines. I took advantage of the fact that jQuery was already included in the project, to save me from some additional lines of code.

All put together, to make my site responsive, I wrote more or less 200 lines of CSS code (with the format above so many lines with only one closing brace). It is not as complicated as you might think.

There is one last important thing. In the header of your pages, add this meta tag to indicate that your site is suitable for mobile devices:

<meta name='viewport' content='width=device-width, initial-scale=1.0'>

Inspection

At the end, the longest and tedious part was to refine styles depending on the resolution. There is no secret, this is an iterative and manual process: change the CSS, refresh the page and check results.

To help you, you can use Responsinator, a good tool to test a site with the most common screen resolutions corresponding to famous devices. You can also install Firesizer, a Firefox extension to know the resolution of the browser window, very useful when building your media queries.