Die Antwort ist simpel: Ich habe sie nicht deaktiviert, sondern lediglich eine eigene, kleine Theme erstellt, welche sicher stellt, dass jeder Benutzer, der auf die Hauptseite “/” zugreift, auf die korrekte URL – in meinem Fall “/en/” oder “/de/” – weitergeleitet wird.

Der folgende Quelltext ist nicht vollständig von mir. Ich erinnere mich, dass ich einfach im Internet nach einer guten Lösung gesucht und diese nach meinen Bedürfnissen angepasst habe, aber das ist schon eine ganze Weile her. Daher weiß ich nicht mehr woher Teile des Quelltexts ursprünglich herstammen.

Egal, hier jedenfalls der Quelltext der Datei index.php, so wie ich sie aktuell in meiner Weiterleitungs-Theme für diese WordPress-Seite verwende:

<?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
 */

/**
 * Browser-Sprache ermitteln.
 *
 * @param array $allowed_languages Ein Datenfeld der Sprachen, die auf der Seite zur Verfügung stehen.
 * @param string $default_language Die zu verwendende Standardsprache, wenn keine ermittelt werden konnte.
 * @param string $lang_variable Benutzerdefinierte Sprachenunterstützung. Wenn nicht übergeben wird specified $_SERVER['HTTP_ACCEPT_LANGUAGE'] verwendet.
 * @param string $strict_mode Wenn true (Standard) wird der gesamte Sprachencode ("en-us") verwendet und nicht nur der linke Teil ("en").
 * @return string Die ermittelte Browser-Sprache.
 */
function get_lang_from_browser($allowed_languages, $default_language, $lang_variable = NULL, $strict_mode = TRUE) {
    // $_SERVER['HTTP_ACCEPT_LANGUAGE'] verwenden, wenn keine Sprachvariable mitgegeben wurde
    if (NULL === $lang_variable)
        $lang_variable = $_SERVER['HTTP_ACCEPT_LANGUAGE'];

    // Wurde irgendwelche Information mitgeschickt?
    if (empty($lang_variable))
        return $default_language;

    // Den Header auftrennen
    $accepted_languages = preg_split('/,\s*/', $lang_variable);

    // Die Standardwerte einstellen
    $current_lang = $default_language;
    $current_q    = 0;
    // Nun alle mitgegebenen Sprachen abarbeiten
    foreach ($accepted_languages as $accepted_language) {
        // Alle Infos dieser Sprache rausholen
        $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;

        // Sprachcode holen und dann sofort in die Einzelteile trennen
        $lang_code = explode('-', $matches[1]);

        // Wurde eine Qualität mitgegeben?
        if (isset($matches[2]))
            $lang_quality = (float)$matches[2];
        else
            $lang_quality = 1.0;

        // Bis der Sprachcode leer ist...
        while (count($lang_code)) {
            // Prüfen, ob der Sprachcode angeboten wird
            if (in_array(strtolower(join('-', $lang_code)), $allowed_languages)) {
                // Qualität prüfen
                if ($lang_quality > $current_q) {
                    $current_lang = strtolower(join('-', $lang_code));
                    $current_q = $lang_quality;
                    break;
                }
            }
            // Wenn wir im strengen Modus sind, die Sprache nicht versuchen zu minimalisieren
            if ($strict_mode)
                break;

            // Den rechtesten Teil des Sprachcodes abschneiden
            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();
?>

Sie müssen also lediglich ein neues Theme-Verzeichnis anlegen und den obigen PHP-Quelltext (wenn nötig natürlich noch die erlaubten Sprachen anpassen) in eine Datei namens index.php kopieren.

Danach ist nur noch zusätzlich eine Dummy-Datei style.css mit einigen Infos zum Theme zu erstellen. Ansonsten wird WordPress Ihre Theme nicht erkennen:

/*
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
*/

Das war’s: Nachdem Sie diese neue Theme für Ihre Hauptseite “/” ausgewählt haben, wir automatisch jeder Benutzer auf die korrekte Spracheversion basierend auf den Browser-Spracheinstellungen weiter geleitet.

Verwenden auch Sie den Multisite Language Switcher für Ihren Blog?

Dieses Plug-In fasst mein Widget zur Anzeige von Flaggen zur Sprachauswahl im Menü und in der Fußzeile mit vielen zusätzlichen Optionen und Einstellungsmöglichkeiten in ein sauberes WordPress-Plug-In zusammen.

Die Installation und Konfiguration ist sehr einfach. Probieren Sie es aus schreiben Sie mir Ihre Meinung!

Nun stellt sich die Frage:
Warum noch ein weiteres Social-Widgets-Plug-In, zumal es hier bereits jede Menge gibt?

Die Antwort ist, dass ich nach einem einfachen und leicht zu verwendenten Plug-In gesucht habe und alle Plug-Ins, die ich fand, waren schlicht und ergreifend zu kompliziert: Ich wollte keine unzähligen unterstützen, sozialen Netzwerke mit hunderten an Optionen – einfach ein simples Plug-In, welches die wichtigsten Social Widgets abdeckt, ohne dass hierbei eine Konfiguration erforderlich ist!

Und genau das ist mein neues Plug-In:
Installieren Sie es, aktivieren Sie es und die Social Widgets werden sofort unter Ihren Artikeln angezeigt – ganz ohne Konfiguration.

Welches Social-Widgets-Plug-In verwenden Sie?

Zunächst muss hierfür das Kontrollkästchen “Die WordPress, Movable Type, MetaWeblog und Blogger XML-RPC Schnittstelle aktivieren.” im Menü “Einstellungen”/”Schreiben” aktiviert werden.

Nun suchte ich nach einer direkt verwendbaren Lösung im Internet, da ich sicherlich nicht der Erste war, der Ähnliches bewerkstelligen wollte. Wie erwartet gab es auch eine ganze Reihe von PHP-Skripten, die genau das taten, jedoch mit einem Problem:
Ich wollte auch das Veröffentlichungsdatum manuell mit dem PHP-Aufruf setzen und die meisten Skripte, die ich gefunden hatte, versuchten nicht einmal das zu tun.

Wenige Skripte versuchten zwar das Veröffentlichungsdatum zu setzen, aber das Ergebnis war eine Fehlermeldung ähnlich dieser:
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

Nachdem ich einige Dokumente über dieses seltsame ISO-8601-Datumsformat gelesen hatte, fand ich selbst eine Lösung:

/**
 * Führt einen XML-RPC zu einem WordPress-Blog aus und fügt einen Artikel hinzu.
 *
 * @param string $title Titel des neuen Artikels.
 * @param string $body Inhaltstext des neuen Artikels.
 * @param string $rpcurl RPC-URL des Blogs (meist xmlrpc.php im Stammverzeichnis).
 * @param string $username Benutzername, der zum Hinzufügen des neuen Artikels verwendet wird.
 * @param string $password Passwort, das zum Hinzufügen des neuen Artikels verwendet wird.
 * @param string $categories Komma-getrennte Liste von Kategorien (stellen Sie sicher, dass diese in Ihrem Blog bereits existieren).
 * @param string $keywords Komma-getrennte Liste von Schlüssel-/Schlagwörtern (im Gegensatz zu den Kategorien müssen diese noch nicht existieren).
 * @param string $pubdate Veröffentlichungsdatum in ISO 8601 (mittels date('c') in PHP; aktuelle Zeit wird verwendet, wenn leer).
 * @param string $draftonly True, um nur als Entwurf abzuspeichern, False um es direkt zu veröffentlichen (Standard).
 * @return string Das Ergebnis des 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%', // Nur als Platzhalter hier.
		'mt_keywords' => $keywords,
		'categories' => array($categories)
	);
	$params = array(0, $username, $password, $content, !$draftonly);

	$request = xmlrpc_encode_request('metaWeblog.newPost', $params);
	// Nun müssen wir das eigentliche Veröffentlichungsdatum setzen:
	$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;
}

Wie Sie sehen können, habe ich die für das korrekte ISO-8601-Datumsformat benötigte Datenstruktur einfach direkt selbst in den XML-Aufruf eingefügt. Das mag vielleicht nicht die eleganteste Lösung sein, sie funktioniert jedoch einwandfrei.

Sind Sie selbst auch bereits auf dieses Problem gestoßen?

Der Multisite Language Switcher erlaubt Ihnen einfach eine WordPress-Multisite-Konfiguration mit einer WordPress-Administration für jede Blogsprache zu nutzen und trotzdem eine Beziehung zwischen den Sprachversionen Ihrer Artikel, Kategorien und Schlagwörter zu erhalten.

Das ist hervorragend, denn dadurch gibt es das Problem der anderen Übersetzungs-Plug-Ins nicht mehr, dass Sie immer darauf achten mussten, dass jedes zusätzlich verwendete Plug-In (wie ein spezielles SEO-Plug-In) auch das verwendete Übersetzungs-Plug-In unterstützt. Ansonsten konnte man beispielsweise keine Übersetzung für den Seitentitel oder die Beschreibung einfügen, was SEO-technisch jedoch wichtig ist.

Aber das ist mit diesem Plug-In kein Problem: Da es nur von der standardmäßigen und offiziellen Funktionalität einer WordPress-Multisite-Konfiguration abhängt, können Sie jedes beliebige Plug-In verwenden, dass die WordPress-Multisite-Funktionalität unterstützt.

Nun könnte man sagen, dass es unpraktisch ist, dass man sich in einen anderen WordPress-Adminbereich einloggen muss, um eine Übersetzung zu verändern. Aber mit der aktuellen Version des Plug-Ins wird jede Übersetzung direkt im Admin-Bereich verlinkt (einfach auf die Sprachflagge klicken). Somit ist es sehr einfach zwischen den verschiedenen Übersetzungen im Editiermodus zu wechseln.

Selbstverständlich können Sie dieses Plug-In hier in Aktion sehen:
Es kann unter jedem Artikel einen Link zu dessen Übersetzungen hinzufügen. Zusätzlich sind die auf den Blog-Seiten angezeigten Flaggen auch direkt mit den Übersetzungen der aktuellen Seite verlinkt.

Im Ergebnis kann ich nur jedem, der nach einer Lösung für einen mehrsprachigen Blog mit WordPress sucht, empfehlen dieses Plug-In zu testen.

Kennen Sie noch andere gute Lösungen für mehrsprachige Blogs mit WordPress?

Download Sie hier die deutsche Übersetzungsdatei:

• 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

Einfach die Übersetzungsdateien in das Verzeichnis /mailpress/mp-content/languages/ entpacken.

Falls Sie Fehler finden, bitte unten posten!

Dabei hat sich herausgestellt, dass insbesondere die Einbindung von Bildern auf der rechten Seite des (standardmäßig schwarzen) Menübereichs im Design “Twenty Eleven” nicht gerade einfach ist. Daher entschied ich mich dazu, einfach ein kleines Widget zu erstellen, das die Flaggen in einem DIV anzeigt, welches über dem gesamten anderen Inhalt platziert ist und so ganz einfach mit relativen Koordinaten direkt aus dem Admin-Widget-Interface positioniert werden kann.

Folgende Einstellungen können somit im Admin-Bereich getroffen werden:

• Positionsabstand der Flagge (links): Der relative Abstand der X-Koordinate des DIVs.
• Positionsabstand der Flagge (oben): Der relative Abstand der Y-Koordinate des DIVs.
• Icon-URL der Flagge (en): Die Icon-URL der englischen Flagge (natürlich zurvor hochgeladen).
• Icon-URL der Flagge (de): Die Icon-URL der deutschen Flagge (natürlich zurvor hochgeladen).

Selbstverständlich kann das problemlos mit weiteren oder anderen Sprachen erweitert werden.

Und hier ist der Quelltext des Widgets:

<?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");'));
?>

Ich wollte es so einfach wie möglich halten und daher ist alles zusammen in einer Datei. Ansonsten sollte man natürlich zumindest die CSS-Styles in eine externe Style-Sheet-Datei packen.

Daher wollte ich nur Ausschnitte der Artikel auf den folgenden Seiten anzeigen lassen:

• Suchergebnisseiten (was bereits standardmäßig der Fall ist)
• Startseite des Blogs
• Kategorie-Seiten
• Schlagwort-Seiten
• Datum-basierte Archiv-Seiten (die ich zurzeit überhaupt nicht nutze)

Um das zu erreichen, muss man lediglich im Theme die Zeile in der Datei “content.php”

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

mit dieser ersetzen:

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

Das war’s. Nun finde zumindest ich, dass es für den Benutzer besser aussieht und die Suchmaschinen haben sicherlich auch nichts dagegen (Stichwort: “duplicate content”).

Enttäuscht stellte ich fest, dass WordPress noch immer von Hause aus keine Möglichkeit für mehrsprachige Blogs mitbringt. Das kann ich überhaupt nicht nachvollziehen, da offenbar sehr viele Leute genau dieses Problem haben: Wie bekommt man den WordPress-Blog mehrsprachig.

Während ich nach einer Lösung suchte, fand ich grundsätzlich drei sinnvolle Optionen:

• Plug-In qTranslate
• Plug-In WPML
• Die Multisite-Funktion von WordPress selbst

qTranslate

Als ich dieses Plug-In testete, sah ich recht schnell, dass es keine Übersetzung von Slugs (URL-Variante des Namens) für Artikel, Seiten, Kategorien und Schlagwörter unterstützt. Somit ist dieses Plug-In meiner Meinung nach nutzlos, da ohne eine Slug-Übersetzung die Suchmaschinenoptimierung praktisch unmöglich ist.

Offensichtlich hat der ursprüngliche Plug-In-Entwicklung bisher keine Lust oder Zeit gehabt diese Funktion zu implementieren, aber obwohl es inzwischen andere Leute gibt, die sich mit diesem Problem beschäftigen (siehe dieser Forum-Beitrag (Englisch)), wollte ich nun kein derart unvollständiges Plug-In nutzen.

WPML

Auf den ersten Blick sah WPML wie eine gute Alternative aus. Es ist zwar nicht (mehr) kostenlos, aber ich habe nichts dagegen ein paar Dollar für ein gutes Plug-In zu bezahlen.

Jedoch sprechen folgende Gründe gegen eine Nutzung, weswegen ich die Rückerstattung meines Geldes (was innerhalb 30 Tagen möglich ist) beantragt habe:

1. Ich möchte sämtliche Sprachen (inklusive der Standardsprache) in einem Unterverzeichnis haben und das wird von WPML nicht unterstützt.
   Die in diesem Forum geschilderte Hilfslösung (Englisch) ist mir ein bisschen zu provisorisch (man weiß nie, welche Probleme man später mit solchen “Hacks” haben wird).
2. Es ist unpraktisch, dass WPML es nicht erlaubt Kategorien und Schlagwörter mit denselben Namen und Slugs für verschiedene Sprachen zu haben. Wenn die verschiedenen Sprachen in Unterverzeichnissen (oder sogar Sub-Domains) platziert sind, gibt es keinen Grund, dass die Namen und Slugs sprachübergreifend eindeutig sein müssen.
3. In WPML gibt es einen Bug, dass Artikel Ihre Übersetzungszuordnung zueinander verlieren. Bisher wurde keine Erklärung oder Lösung hierfür angeboten. (Englisch)

Aber ich möchte hinzufügen, dass die Rückerstattung des Geldes, wie von dem Unternehmen versprochen, sehr schnell (innerhalb weniger Stunden) erfolgt ist; so kann jeder WPML selbst gefahrlos testen.

WordPress Multisite

Logischerweise gibt es nun nicht mehr viele weitere Optionen. Somit bleibt nur diese.

Natürlich gibt es auch dabei einen Nachteil: Übersetzte Artikel sind nicht direkt miteinander verbunden und somit kann der Leser nicht einfach zu einer anderen Sprache des Artikels wechseln. Aber vielleicht erstelle ich dafür selbst noch ein Plug-In, um das zu korrigieren.

In jedem Fall ist man bei dieser Lösung nicht auf irgendwelche fremden Plug-Ins für mehrsprachige Blogs angewiesen.

Hier erkläre ich wie Sie bei Verwendung von WordPress Multisite dennoch Flaggen zur Sprachauswahl anzeigen können.

Und welche Variante verwenden Sie für Ihren mehrsprachigen Blog?

Dann traf ich auf Dotclear (Englisch), das auf den ersten Blick nach einer interessanten Alternative aussah:

• Es sieht schlicht und einfach aus.
• Es ist in PHP geschrieben (da ich selbst auch in PHP entwickle, ist das für mich wichtig, falls es nötig sein sollte selbst einmal etwas hinzuzufügen oder anzupassen).
• Es sollte einfach möglich sein mehr als eine Sprache für den Blog zu verwenden (was ja der Grund ist, weswegen ich mit WordPress unzufrieden bin).

Daher startete ich einen Versuch und installierte es auf meinem Test-Server, was ohne Probleme oder Fehler funktionierte.

Direkt nach dem ersten Login wollte ich einen Blick in die Dokumentation und die Plug-In-Beschreibungen werden, um zu sehen, welche Plug-Ins für dieses System verfügbar sind. Dann war ich jedoch ziemlich erschrocken: Sämtliche Plug-In-Beschreibungen sowie ein Teil der Dokumentation scheinen nur auf Französisch zur Verfügung zu stehen!

Vielleicht könnte ich es mit Hilfe meiner schulischen Lateinkenntnisse und Google Translate trotzdem verstehen, aber ich möchte wirklich kein Blog-System verwenden, welches als Hauptsprache nicht Englisch hat.

Obwohl ich muttersprachlich Deutsch spreche, sollte meiner Meinung nach ein größeres Open-Source-Projekt nicht einmal Deutsch als Hauptsprache wählen: Gib es Übersetzungen in anderen Sprache, ist das natürlich super, aber die meisten Leute verstehen nun mal Englisch und daher sollte die Hauptsprache eines Projektes auch Englisch sein! Punkt.

Somit habe ich den Test mit Dotclear abgebrochen und bleibe bei WordPress.

Haben Sie auch bereits positive oder negative Erfahrungen mit Dotclear gemacht?