Having qTranslate, multilingual WordPress plugin, installed, brings some problems – between them are slower performance and incompatibility with other plugins. It is said, that having a XML sitemap helps you climb on Google rankings. And you can find a few plugins which support this. One of them is Google XML Sitemaps but it has a broken qTranslate support. This was fixed by a forked Google XML Sitemaps with qTranslate Support, but unfortunately it is not up to date and doesn’t translate categories and tags.

So, some coding was needed. To transfer the enhancement to the original plugin, I wrote two functions, which are stored in a separate file, so the new code does not intermingle with the original one. I also enhanced the functionality, so that besides URLs for home page and posts, the URL is translated for categories, tags, archives and author pages. It also works as correctly for enabling/disabling qTranslate’s “hide_default_language” option.

Download the latest version of »Google XML Sitemaps for qTranslate« plugin. Zip file contains the original and modified file “sitemap-core.php” and a new one “sitemap-qtranslate.php”.

To do: translation of URLs for subposts, static pages, taxonomy pages.

Update on 3rd of June: Corrected display of “last modification time” in “sitemap-qtranslate.php”.
Update on 4th of June: Corrected URL translations when not using qTrasnlate option “URL Modification Mode” set to “Use Pre-Path Mode”.
Update on 19th of August: The code was packed as an official WordPress plugin.

Installing a qTranslate, multi-language enabling WordPress plugin, can increase the time in which your blog loads.

My installation of the blog, with all the plugins (including qTranslate), loads in about 600ms. Disabling qTranslate reduces the load time to 320ms.

To see what is happening I installed Xdebug and WebGrind for making a performance review of WordPress and qTranslate. Xdebug is probably a package in your Linux distribution (at least it comes with Ubuntu Server as php5-xdebug). Instructions for installation and usage can be found here.

And the WebGrind screenshot:

As you can see, function named “qtrans_use” takes 20% of all loading time. Combined with all “qtrans*” functions, the share goes to more than 30%. That is really inefficient compared to the analysis with qTranslate disabled – note that the loading times are lot longer with Xdebug enabled:

As none of those two options are satisfactory, I tried to optimize qTranslate. Expanding “qtrans_use” function reveals that 48% of calls are recursive (function calls itself) and for 38% a function “qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage” is to blame:

After a little searching I found out that WordPress options are getting translated too. Unfortunately there is no cache implemented to remember the translations so the whole list gets translated every time one option is called. So I disabled (just put a # or // in front) the line “add_filter (‘option_’.$option, ‘qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage’, 0);” in “qtranslate_core.php”, which is located in “wp-content/plugins/qtranslate”. This improved the loading times a bit – to 480ms. A 120ms improvement. Not much, but it helps when a Google crawler goes through hundreds of pages.

You can see that number of calls of “qtrans_use” were reduced form 13517 to 2221. qTranslate now contributes little more than 12% to the whole loading time. There is some room for improvement, but probably this includes substantial modifying of the plugin. You must also know, that some plugins can have their options translated and in that case add a little “if” conditional clause around that “add_filter” call to let only the desired options through.