The answer is simple: I did not disable it, but just created an own, small redirect theme to make sure every user accessing the main site “/” is redirected to the correct language URL – in my case either “/en/” or “/de/”.

The following source code isn’t completely from me. I remember that I just searched the web for a good solution and changed it as I needed it, but that’s a longer time ago. Therefore no idea where parts or this code are from originally.

Anyway, here is the source code of the file index.php of my redirect theme just as I use it on this WordPress site right now:

<?php
/**
 * The main template file.
 *
 * This is the most generic template file in a WordPress theme
 * and one of the two required files for a theme (the other being style.css).
 * It is used to display a page when nothing more specific matches a query.
 * E.g., it puts together the home page when no home.php file exists.
 * Learn more: http://codex.wordpress.org/Template_Hierarchy
 *
 * @package WordPress
 * @subpackage Redirect
 */

/**
 * Detect browser language.
 *
 * @param array $allowed_languages An array of languages that are available on the site.
 * @param string $default_language Default language to use if none could be detected.
 * @param string $lang_variable Custom user language support. If not specified $_SERVER['HTTP_ACCEPT_LANGUAGE'] is used.
 * @param string $strict_mode If true (default) the whole language code ("en-us") is used and not only the left part ("en").
 * @return string The detected browser language.
 */
function get_lang_from_browser($allowed_languages, $default_language, $lang_variable = NULL, $strict_mode = TRUE) {
    // Use $_SERVER['HTTP_ACCEPT_LANGUAGE'] if no language variable is available
    if (NULL === $lang_variable)
        $lang_variable = $_SERVER['HTTP_ACCEPT_LANGUAGE'];

    // Any info sent?
    if (empty($lang_variable))
        return $default_language;

    // Split the header
    $accepted_languages = preg_split('/,\s*/', $lang_variable);

    // Set default values
    $current_lang = $default_language;
    $current_q    = 0;
    // Now work through all included languages
    foreach ($accepted_languages as $accepted_language) {
        // Get all info about this language
        $res = preg_match(
            '/^([a-z]{1,8}(?:-[a-z]{1,8})*)'.
            '(?:;\s*q=(0(?:\.[0-9]{1,3})?|1(?:\.0{1,3})?))?$/i',
            $accepted_language,
            $matches
        );

        if (!$res)
            continue;

        // Get language code and split into parts immediately
        $lang_code = explode('-', $matches[1]);

        // Is there a quality set?
        if (isset($matches[2]))
            $lang_quality = (float)$matches[2];
        else
            $lang_quality = 1.0;

        // Until the language code is empty...
        while (count($lang_code)) {
            // Check if the language code is available
            if (in_array(strtolower(join('-', $lang_code)), $allowed_languages)) {
                // Check quality
                if ($lang_quality > $current_q) {
                    $current_lang = strtolower(join('-', $lang_code));
                    $current_q = $lang_quality;
                    break;
                }
            }
            // If we're in strict mode we won't try to minimalize the language
            if ($strict_mode)
                break;

            // Cut the most right part of the language code
            array_pop($lang_code);
        }
    }

    return $current_lang;
}

$allowed_langs = array('en', 'de');
$lang = get_lang_from_browser($allowed_langs, 'en', NULL, FALSE);
header('Location: http://' . $_SERVER['HTTP_HOST'] . "/$lang/");

exit();
?>

So just create a new theme folder and copy the PHP code above (change the allowed languages if needed, of course) into a file named index.php.

Then you just need to create an additional dummy file style.css with some info about the theme. Otherwise WordPress won’t recognize your theme:

/*
Theme Name: Redirect
Theme URI: http://wordpress.org/extend/themes/redirect
Author: AB-WebLog.com
Author URI: http://www.ab-weblog.com
Description: Redirects
Version: 1.0
Tags: redirect
*/

That’s it: after you have seleted this new theme for your main site “/”, every user will automatically be redirected to the correct language version based on the browser language settings.

Do you use the Multisite Language Switcher or your blog, too?

First of all you need to enable the checkbox “Enable the WordPress, Movable Type, MetaWeblog and Blogger XML-RPC publishing protocols.” in the menu “Settings”/”Writing”.

Now I searched on the web for a ready-to-use solution as I was probably not the first one who wanted to accomplish that. And as expected there were also many PHP scripts doing exactly that, but with one problem:
I wanted to set also the publishing date manually with the PHP request and most scripts I’ve found did not even try to do that at all.

Few scripts in fact did try to set the publishing date, but the result was an error message similar to:
Fatal error: Call to a member function getIso() on a non-object in /var/www/wp-includes/class-wp-xmlrpc-server.php on line 2373

After reading some documents regarding this strange ISO 8601 date format that is needed there, I found a solution myself:

/**
 * Performs a XML-RPC to a WordPress blog and adds a new post.
 *
 * @param string $title Title of the new post.
 * @param string $body Body text of the new post.
 * @param string $rpcurl RPC-URL of the blog (normally xmlrpc.php in the root directory).
 * @param string $username User name used to add the new post.
 * @param string $password Password used to add the new post.
 * @param string $categories Comma separated list of categories (make sure they already exist in your blog).
 * @param string $keywords Comma separated list of keywords/tags (in contrast to the categories they don't need to exist already).
 * @param string $pubdate Publishing date in ISO 8601 (with date('c') in PHP; current time is used if empty).
 * @param string $draftonly True to save as draft only, False to publish directly (default).
 * @return string The result of the XML-RPC.
 */
function wpPostXMLRPC($title, $body, $rpcurl, $username, $password, $categories, $keywords = '', $pubdate = '', $draftonly = false) {
	$content = array(
		'title' => $title,
		'description' => $body,
		'mt_allow_comments' => 1,
		'mt_allow_pings' => 1,
		'post_type' => 'post',
		'date_created_gmt' => '%pubdate%', // Just as place holder here.
		'mt_keywords' => $keywords,
		'categories' => array($categories)
	);
	$params = array(0, $username, $password, $content, !$draftonly);

	$request = xmlrpc_encode_request('metaWeblog.newPost', $params);
	// Now we need to set the real publishing date:
	$request = str_replace('<string>%pubdate%</string>',
			       '<dateTime.iso8601>' . $pubdate . '</dateTime.iso8601>',
			       $request);

	$ch = curl_init();
	curl_setopt($ch, CURLOPT_POSTFIELDS, $request);
	curl_setopt($ch, CURLOPT_URL, $rpcurl);
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	curl_setopt($ch, CURLOPT_TIMEOUT, 1);
	$results = curl_exec($ch);
	curl_close($ch);
	return $results;
}

As you can see I inserted the data structure needed for the correct ISO 8601 date format myself directly into the XML request. This is probably not the most elegant way, but it works perfectly.

Did you come across the same issue already yourself?

The Multisite Language Switcher allows you to simply use a multisite WordPress configuration with one WordPress administration for every blog language and still have a relation between the language versions of your posts, categories and tags.

That’s really great, because this way you don’t have the problem with all these translation plug-ins that you always have to make sure that every additional plug-in you use (like a special SEO plug-in) also supports the used translation plug-in. Otherwise you cannot add let’s say a translation for your page title or description which is important for SEO reasons.

But not with this plug-in: as it depends only on the default and official functionality of a WordPress multisite configuration, you can use whatever plug-in that supports the WordPress multisite functionality.

You may say it is unfunctional that you need to login to another WordPress admin area to change a translation. But with the current version of this plug-in each translation is linked in the admin area directly (just click on the language flag). This way it is very easy to switch between different translations in the edit mode.

You can see this plug-in in action here, of course:
it can add a link below every post to its translations. Additionally the flags displayed on the blog pages link directly to the translations of the current page, too.

As a summary I can only recommend to try this plug-in if you are searching for a solution to build a multilingual blog in WordPress.

Do you know other good solutions for multilingual blogs in WordPress?

Download the German translation file:

• MailPress-5.3.0-de_DE.zip
• MailPress-5.2.1-de_DE.zip
• MailPress-5.1.1-de_DE.zip
• MailPress-5.1-de_DE.zip

Just unzip the translation files into the folder /mailpress/mp-content/languages/.

If you find mistakes, please post below!

It turned out that especially the integration of images on the right side of the (by default black) menu area was not very easy in the “Twenty Eleven” theme. Therefore I decided to just create a simple widget that displays the flags in a DIV which is placed above all other content and this way can easily be positioned with relative coordinates directly from within the admin widget interface.

Therefore you can define these settings in the admin area:

• Flag position offset (left): the relative offset of the X coordinate of the DIV.
• Flag position offset (top): the relative offset of the Y coordinate of the DIV.
• Flag icon URL (en): the flag icon URL for the English flag (first uploaded, of course).
• Flag icon URL (de): the flag icon URL for the German flag (first uploaded, of course).

Obviously this can be easily extended with more or other languages if needed.

And here is the widget source code:

<?php
/**
 * Flags_Widget Class
 */
class Flags_Widget extends WP_Widget {
	/** constructor */
	function Flags_Widget() {
		parent::WP_Widget(false, $name = 'Flags_Widget');
	}

	/** @see WP_Widget::widget */
	function widget($args, $instance) {
		extract($args);
		?>
			<div style="position: relative;">
				<div style="left: <?php echo $instance['flags_position_left']; ?>px; top: <?php echo $instance['flags_position_top']; ?>px; position: absolute; z-index: 10000 !important;">
					<?php echo '<a href="/en/"><img src="' . $instance['flag_en'] . '" width="20" height="16" title="English" alt="English" />'; ?></a>  
					<?php echo '<a href="/de/"><img src="' . $instance['flag_de'] . '" width="20" height="16" title="Deutsch" alt="Deutsch" /></a>'; ?>
				</div>
			</div>
		<?php
	}

	/** @see WP_Widget::update */
	function update($new_instance, $old_instance) {
		$instance = $old_instance;
		$instance['flags_position_left'] = strip_tags($new_instance['flags_position_left']);
		if (!is_numeric($instance['flags_position_left'])) $instance['flags_position_left'] = '0';
		$instance['flags_position_top'] = strip_tags($new_instance['flags_position_top']);
		if (!is_numeric($instance['flags_position_top'])) $instance['flags_position_top'] = '0';
		$instance['flag_en'] = strip_tags($new_instance['flag_en']);
		$instance['flag_de'] = strip_tags($new_instance['flag_de']);
		return $instance;
	}

	/** @see WP_Widget::form */
	function form($instance) {
		$flags_position_left = esc_attr($instance['flags_position_left']);
		if ($flags_position_left == '') $flags_position_left = '0';
		$flags_position_top = esc_attr($instance['flags_position_top']);
		if ($flags_position_top == '') $flags_position_top = '0';
		$flag_en = esc_attr($instance['flag_en']);
		$flag_de = esc_attr($instance['flag_de']);
		?>
			<p>
				<label for="<?php echo $this->get_field_id('flags_position_left'); ?>"><?php _e('Flag position offset (left):'); ?></label>
				<input class="widefat" id="<?php echo $this->get_field_id('flags_position_left'); ?>"
					name="<?php echo $this->get_field_name('flags_position_left'); ?>" type="text" value="<?php echo $flags_position_left; ?>" />
				<label for="<?php echo $this->get_field_id('flags_position_top'); ?>"><?php _e('Flag position offset (top):'); ?></label>
				<input class="widefat" id="<?php echo $this->get_field_id('flags_position_top'); ?>"
					name="<?php echo $this->get_field_name('flags_position_top'); ?>" type="text" value="<?php echo $flags_position_top; ?>" />
				<label for="<?php echo $this->get_field_id('flag_en'); ?>"><?php _e('Flag icon URL (en):'); ?></label>
				<input class="widefat" id="<?php echo $this->get_field_id('flag_en'); ?>"
					name="<?php echo $this->get_field_name('flag_en'); ?>" type="text" value="<?php echo $flag_en; ?>" />
				<label for="<?php echo $this->get_field_id('flag_de'); ?>"><?php _e('Flag icon URL (de):'); ?></label>
				<input class="widefat" id="<?php echo $this->get_field_id('flag_de'); ?>"
					name="<?php echo $this->get_field_name('flag_de'); ?>" type="text" value="<?php echo $flag_de; ?>" />
			</p>
		<?php
	}
} // class Flags_Widget
add_action('widgets_init', create_function('', 'return register_widget("Flags_Widget");'));
?>

I wanted to keep it simple and therefore all together in one file. Otherwise you should at least put the CSS styles inside an external style sheet file, of course.

Therefore I wanted to display only excerpts of posts for following pages:

• Search results (which is the case by default already)
• Homepage of the blog
• Category archive pages
• Tag archive pages
• Date-based archive pages (I don’t use them at all right now)

To accomplish that, you just have to replace the line in the “content.php” theme file

<?php if ( is_search() ) : // Only display Excerpts for Search ?>

with this one:

<?php if ( is_home() || is_tag() || is_category() || is_date() || is_search() ) : ?>

That’s it. Now at least I think it looks better for the user and I’m sure also search engines don’t mind that (keyword: “duplicate content”).

Disappointed I realized that WordPress still does not provide options for multilingual blogs originally. I don’t understand that, because obviously many people have exactly this problem: how to get the WordPress blog multilingual.

While searching for a solution, I basically found three useful options:

• Plug-in qTranslate
• Plug-in WPML
• Using the multisite feature of WordPress itself

qTranslate

When I tested this plug-in I saw quite fast that it does not provide slug translation for posts, pages, categories and tags. This way this plug-in is useless in my opinion, because without a slug translation search engine optimization is basically impossible.

Obviously the original plug-in developer did not like or had no time to implement that feature yet, but although there are already other guys dealing with that issue (see this forum post), I don’t want to use such an incomplete plug-in right now.

WPML

On the first sight WPML looks like a good alternative. It is not free (anymore), but I don’t mind paying some dollars for a good plug-in.

But there are following reasons why I will not use it and asked for refunding my money (which is possible within 30 days):

1. I want to have all languages (including the default one) in a subdirectory and this is not supported by WPML. The workaround provided in the forum is a little bit too “hacky” (you never know which problems you’ll get with such hacks later on).
2. it is unhandy that WPML does not allow to have tags and categories with the same names and slugs for different languages. If different languages are placed in a subdirectory (or even subdomain), there is no need to have cross-language unique names and slugs.
3. there is a bug in WPML where posts are losing the translation relation to each other. No explanation or solution was provided therefore till now.

But I would like to add that refunding the money was done very fast (within few hours) as promised by the company; so it’s save to test WPML yourself.

WordPress Multisite

Obviously there are not many options left. Therefore I go this way now.

Of course, there is a drawback with this solution, too: translated posts are not directly linked to each other and therefore the reader cannot switch to another language of the post easily. But maybe I’ll create a plug-in to fix this later on myself.

At least you don’t need to rely on other plug-ins for multilingual blogs with this solution.

Here I explain how to add language selection flags although using WordPress Multisite.

And which option you are using for your multilingual blog?

Then I found Dotclear that looked at first sight like a interesting alternative:

• It looks clean and easy.
• It’s written in PHP (as I’m developing in PHP myself, too, that’s important for me in case it should be necessary to add or change something myself).
• It should be easily possible to use more than one language for the blog (that’s the reason why I’m unhappy with WordPress).

Therefore I just gave it a try and installed it on my test server which worked without problems and errors.

Directly after the first login I wanted to have a look inside the documentation and the plug-in descriptions to see what plug-ins are available for this system. But then I was appalled: all plug-in descriptions and part of the documentation seem to be only available in French!

Maybe I could still understand it by using my school’s Latin knowledge and Google Translate, but I really don’t want to use a blogging system that’s main language is not English.

Although I’m a German native speaker, I even don’t think any bigger open source project should choose German as main language: if there are translations in other languages that’s great, of course, but as most of all people understand English, the main language of all projects should be English! Period.

Therefore I stopped testing Dotclear and stayed with WordPress.

Did you also have positive or negative experience with Dotclear yourself already?