RealURL mehrsprachig: pro Domain eine Sprache ohne Get-Parameter / preVars
Bei der Umsetzung von mehrsprachigen Websites (multilingual) mittels TYPO3 hat man die Wahl zwischen zwei verschiendenen Konzepten:
- Mehrere Seitenbäume (pro Sprache ein Seitenbaum):
Dieses Konzept ist sehr einfach umzusetzen. Jedem Seitenbaum wird ein Domainrecord zugewiesen und mittels einer TypoScript-Condition kann der Host abgefragt und die gewünschte Sprache zugewiesen werden. Lösungsansätze findet man wie Sand am Meer, darum werde ich hierauf nicht weiter eingehen. - Ein Seitenbaum für alle Sprachen (one tree fits all):
Die angeforderte Sprache wird über einen Get-Parameter (oft “L”) abgefragt, welcher bei suchmaschinenfreundlichen (SEF) URLs dennoch immer Bestandteil der URL ist. Die verbreiteten Lösungsansätze tendieren zu einer Verwendung von RealURL-preVars.
“One tree fits all” ohne sichtbaren Get-Parameter / preVars
Angenommen es soll eine zweisprachige Website (deutsch + englisch) über zwei Domains (www.website.de + www.website.com) über einen Seitenbaum realisiert werden, dann stellt sich die Frage, wie man die überflüssigen Get-Parameter für die Spracherkennung aus der URL herausbekommt, denn die Unterscheidung kann ja schon anhand der aufgerufenen Domain getroffen werden. So würde beispielsweise die URLs für eine Seite Aktuelles/News aussehen, wenn man sich an die verbreiteten Lösungsansätze hält:
http://www.domain.de/de/aktuelles/
http://www.domain.com/en/news/
Das ist zwar schon suchmaschinenfreundlich (SEF), kann aber noch weiter optimiert werden (SEO):
http://www.domain.de/aktuelles/
http://www.domain.com/news/
Ohne die überflüssigen Pfad-Segmente “de” und “en” muss man RealURL aber dennoch mitteilen, in welcher Sprache die aufgerufene Seite angezeigt werden soll. Diese Sprachweiche (nachträgliches Einfügen der Get-Parameter) baut man in der localconf.php vor der RealURL-Konfiguration ein:
// Host abfragen und getVar setzen:
switch(t3lib_div::getIndpEnv('HTTP_HOST')){
case 'www.domain.de';
$_GET['L'] = 0;
break;
case 'www.domain.com';
$_GET['L'] = 1;
break;
}
Diese Fallunterscheidung kann man natürlich um beliebig viele Domains erweitern. (Eine Alterative zu diesem Script: s.u. – Kommentar von Michael Fritz)
Und so könnte die darauf folgende RealURL-Konfiguration aussehen:
$TYPO3_CONF_VARS['EXTCONF']['realurl'] = array(
'_DEFAULT' => array(
'init' => array(
'enableCHashCache' => 1,
'appendMissingSlash' => 'ifNotFile',
'enableUrlDecodeCache' => 1,
'enableUrlEncodeCache' => 1,
),
'preVars' => array(
array(
'GETvar' => 'L',
'valueMap' => array(),
'noMatch' => 'bypass',
),
),
'pagePath' => array(
'type' => 'user',
'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',
'spaceCharacter' => '-',
'languageGetVar' => 'L',
'expireDays' => 7,
'disablePathCache' => 0,
'rootpage_id' => 1,
),
),
);
Es ist zu beachten, dass zwar die GETvar in den preVars definiert werden musste, es aber keine valueMap gibt, sondern nur das ‘noMatch’ => ‘bypass’, welches jetzt – aufgrund der fehlenden valueMap – immer angewendet wird.
Jetzt müssen die verschiedenen Domains noch im TypoScript (Setup) mittels Conditions unterschieden werden, damit diese Domains den einzelnen Sprachen zugeordnet werden können:
page.config {
simulateStaticDocuments = 0
tx_realurl_enable = 1
prefixLocalAnchors = all
linkVars = L
sys_language_mode = content_fallback
# deutsch:
baseURL = http://www.domain.de/
sys_language_uid = 0
htmlTag_langKey = de-DE
language = de
locale_all = de_DE
}
# englisch:
[globalString = ENV:HTTP_HOST=www.domain.com]
page.config{
baseURL = http://www.domain.com/
sys_language_uid = 1
language = en
locale_all = en_EN
htmlTag_langKey = en
}
[global]
(Konfigurationsvorlage für weitere Sprachen: siehe Artikel TYPO3 Konfiguration für verschiedene Sprachen)
Die gesamte Umsetzung wurde in Zusammenarbeit mit NDH-Websolutions entwickelt.
Abschließend noch ein Tipp bezüglich der RealURL-Konfiguration bei mehreren Domains: Wenn sich für eine zusätzliche Domain nur ein oder wenige Parameter des Array ändern, so empfiehlt es sich den gesamten “_DEFAULT”-Block nicht für jede Domain zu duplizieren, denn die gesamten Parameter kann man bequem über eine einzige Zeile übernehmen (Zeilenumbruch nicht übernehmen!):
$TYPO3_CONF_VARS['EXTCONF']['realurl']['www.domain.com']=
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'];
Mit unset kann man danach bei Bedarf einzelne Felder entfernen (nicht im Falle unsere obigen RealURL-Konfiguration geeignet. Zeilenumbruch nicht übernehmen!):
unset($TYPO3_CONF_VARS['EXTCONF']['realurl']
['www.domain.com']['preVars'][0]['noMatch']);
Werte überschreiben kann man z.B. folgendermaßen, wenn man zuvor den “_DEFAULT”-Block kopiert hat (Zeilenumbruch nicht übernehmen!):
$TYPO3_CONF_VARS['EXTCONF']['realurl']['www.domain.com'];
['pagePath']['rootpage_id'] = 999
Falls Dir dieser Artikel hilfreich war, oder Du eine Anregung oder einen Verbesserungsvorschlag hast, so hinterlasse doch bitte einen Kommentar.
Am 13. Januar 2007 um 16:59 Uhr
super spannende geschichte … klappt das mit jedem browser?
Am 13. Januar 2007 um 17:03 Uhr
Mit Browsern hat das eigentlich nichts zu tun, sondern es geht viel mehr um die URLs, unter denen Seiten in verschiedenen Sprachen ausgeliefert werden.
Am 18. Januar 2007 um 12:44 Uhr
Danke für die super Anleitung!!
-> Was meinte denn der? :-)
Eine gaanz kleine Verbesserung:
$domainset = explode('.',t3lib_div::getIndpEnv('HTTP_HOST'));switch($domainset[count($domainset)-1]){
case 'de':
$_GET['L'] = 1;
break;
case 'es':
$_GET['L'] = 2;
break;
case 'com':
default:
$_GET['L'] = 0;
break;
}
Am 18. Januar 2007 um 12:59 Uhr
Hallo Michael, wenn Du den String erst zerlegst, dann kann die Unterscheidung nur anhand der TLD getroffen werden und das bedeutet, dass beispielsweise Subdomains (www.en.domain.de) nicht abgefangen werden könnnen. Welchen Vorteil siehst Du darin?
Am 18. Januar 2007 um 13:17 Uhr
ok, aber in meinem fall ist es eine erleichterung, weil mein kunde mit subdomains usw. ca. 20 domains hat, die aber alle ausnahmslos über den TDL der jeweiligen Sprache zugeorndet werden können.
Am 31. Januar 2007 um 19:26 Uhr
Wie bekomm ich mit diesen Einstellungen einen LanguageSwitch auf die Website? Ich möchte gern auf jeder Seite eine Sprachauswahl anzeigen. Wenn sich der Benutzer auf www.test.de/kontakt.htm befindet soll er über die Sprachauswahl auf www.test.com/contact.htm kommen usw.
Gibts hierfür auch schon so ein geniales Tutorial? Wäre wirklich super!!!
Am 20. April 2007 um 00:26 Uhr
Ich kann mich Christian nur anschließen. Ich doktor hier auch vergeblich an Sprachumschaltungen für o.g. Methodik rum, bisher ohne Erfolg
Am 22. Juni 2007 um 13:23 Uhr
[…] (wegen der BaseUrl) immer die de Domain angezeigt werden. Dazu habe ich dieses Tutorial gefunden: RealURL mehrsprachig: pro Domain eine Sprache ohne Get-Parameter / preVars Nun habe ich aber ein paar Fragen (vor allem, weil ich das ja bei einer Live Seite machen muss […]
Am 13. Dezember 2007 um 11:09 Uhr
Hmm guter Ansatz - aber der PHP Code in der localconf.php ist nicht nnötig und macht das ganze nur unwartbarer. Dafür gibt es Conditions im typoscript:
[globalString = IENV:HTTP_HOST = *url1.de]
config {
sys_language_uid = 1
language = en
locale_all = en_EN
htmlTag_langKey = en
baseURL = www.url1.de
}
[global]
Am 13. Dezember 2007 um 11:30 Uhr
Hallo Daniel, hast Du das getestet? Conditions verwende ich auch (s.o.) um u.a. die sys_language_uid zu setzen. Soweit ich das richtig in Erinnerung habe, greift RealURL bei der URL-Generierung (sprachabhängige URLs) aber nicht auf die sys_language_uid zurück, sondern auf $_GET[’L'] und diesen Wert kann ich mittels TypoScript nicht überschreiben, oder irre ich mich?
Am 29. Dezember 2007 um 22:27 Uhr
Einen Sprachwechsler kann man beispielsweise so realisieren:
# Language Menu
includeLibs.tx_mylanguage_menu = fileadmin/template/scripts/class.tx_mylanguage_menu.php
temp.menu4.20 = TEXT
temp.menu4.20 {
value = English
typolink.parameter.data = TSFE:id
typolink.additionalParams = &L=1
# typolink.userFunc = tx_mylanguage_menu->main
wrap = |
}
Und die userFunc sieht so aus:
class tx_mylanguage_menu {
function main($content) {
$tag = ‘‘;
return $tag;
}
}
Am 11. Februar 2008 um 16:43 Uhr
Hi,
noch ein Hinweis zur ienv Condition. Bei Mittwald funktioniert nur die, hostname liefert nichts zurück. Ausserdem sollte man bei Umlaut-Domains die Punycode-Schreibweise verwenden. Also für z. B. akdüsseldorf.de:
[globalString = IENV:HTTP_HOST=www.xn--akdsseldorf-vhb.de]
config.baseURL = http://www.akdüsseldorf.de/
[global]
ciao,
Sacha
Am 11. Mai 2008 um 01:38 Uhr
Nettes How-To … man lernt ebend nie aus…. DANKE!
Am 6. Juni 2008 um 16:05 Uhr
Wann stirbt RealUrl endlich aus? Ich hab nur Ärger damit. (Das fängt schon damit an, dass die RealUrl-Auflösungen nicht funktionieren, wenn man im BE engelogggt ist….) Cooluri ist tausendmal einfacher und leistet in etwa das selbe. Kann ich nur jedem empfehlen.
Am 8. September 2008 um 12:18 Uhr
Vielen Dank für den Hinweis von Sacha Vorbeck zur Punycode-Schreibweise bei Mittwald CM Service GmbH.
Ist jemandem schon mal aufgefallen oder kann es allgemein bestätigt werden, dass eine Umlaut-Domain mit .com-Endung im Firefox (aktuellste Version) nicht “richtig” ausgegeben wird, sondern als Punycode?! Es funktioniert in Internet Explorer 7, Opera, Safari, Netscape und Chrome (Beta) - im Firefox jedoch nur als Punycode. Umlaut-Domains mit einer .de-Endung hingegen gehen einwandfrei. Als Beispiel kann man mal müller.de / müller.com oder frisör.de / frisör.com im Firefox und anderen Browsern aufrufen (mit und ohne www). Interessant ist auch der einleitende Hinweis zu Umlaut-Domains auf köln.de. Und will man über die Umlaut-Domain E-Mail nutzen, kann es ohne entsprechende Plugins teilweise Probleme geben. Nach Beschäftigung mit dem Thema Umlaut-Domains, Punycode und Browserverträglichkeit rate ich eher von Umlautdomains ab. Auch aus ganz praktischen Gründen: Wie soll auf normale Weise in z.B. einem englischsprachigen Land eine Umlaut-Domain direkt aufgerufen oder eine E-Mail an diese gesendet werden, wenn man keine Umlaute auf der Tastatur hat …
Grüße,
Frank
Am 9. März 2009 um 17:09 Uhr
wofür braucht man denn noch die Conditions im TS?
Bei mir funktioniert schon wunderbar ohne :
# englisch:
[globalString = ENV:HTTP_HOST=www.domain.com]
….
Am 9. März 2009 um 17:18 Uhr
Die Condition ist dafür da, dass abhängig von der Domain eine andere Sprache gewählt wird und diese auch im HTML-Quelltext entsprechend mkorrekt ausgegeben wird.
Am 10. März 2009 um 11:07 Uhr
Hallo,
Vielen Dank für diese Anleitung. Das hat mein Tag gerettet. ;-)
Ich habe aber noch ein kleines Problem. Ich möchte gern dazu noch unterschiedliche Einstiegsseite abhängig von der Domain.
Wird das nicht mit ‘rootpage_id’ gesteuert? Ich habe für _Default 1 und wollte für meine 2. Domain, dass er zu der Seite 6 geht und habe so gemacht:
$TYPO3_CONF_VARS[’EXTCONF’][’realurl’][’www.domain2.tld’]=$TYPO3_CONF_VARS[’EXTCONF’][’realurl’][’_DEFAULT’];
$TYPO3_CONF_VARS[’EXTCONF’][’realurl’][’www.domain2.tld’][’pagePath’][’rootpage_id’]=’6′;
aber ich bekomme immer die Seite mit id 1 für www.domain2.tld.
PS: Ich habe alle Änderungen von dieser Anleitung übernommen. Ich habe ein one-tree Konzept und möchte für domain2.tld als startseite die seite mit id=6 in englischen Sprache bekommen. Ich kriege aber die seite mit id=1 in englisch.
vielen Dank.
Am 12. März 2009 um 12:06 Uhr
Das müsste mit Domain-Records (List-Modul) im Seitenbaum realisiert werden bzw. alternativ über TYPOScript-Conditions, übder die Du den Inhalt der Startseite abhängig von der Domain aus einem speziellen sysfolder holst :)
Am 7. April 2009 um 15:17 Uhr
Hi,
ich habe Probleme mit dem Sprachumschalter. Ich habe drei Sprachen: Deutsch, Englisch und Niederländisch, für jede TLD eine separate Sprache:
www.domain.de => Deutsch
www.domain.com => Englisch
www.domain.nl => Niederländisch
Die automatische Zuweisung der Sprache nach der Domain klappt soweit auch hier im Tutorial beschrieben. Allerdings bekomme ich keinen Sprachumschalter vernünftig hin, der dann auch die Domain wechselt. Das Beispiel oben von Helmut führt dazu, dass der Link immer auf die aktive Domain zeigt und nicht auf die Sprachabhängige. Hat jemand eine Idee wie man das ändern kann?
Am 7. Mai 2009 um 20:27 Uhr
Mein oben geposteter Sprachumschalter bedurfte noch der Anpassung.
Eine einfachere Lösung ist mir nicht eingefallen, aber es funktioniert wenigstens…
RealURL-Konfig:
‘preVars’ => array(
array(
‘GETvar’ => ‘L’,
‘valueMap’ => array(),
‘noMatch’ => ‘bypass’,
),
array(
‘GETvar’ => ‘LS’,
‘valueMap’ => array(
‘de’ => ‘0′,
‘en’ => ‘1′,
),
‘noMatch’ => ‘bypass’,
),
),
Typoscript:
# Language Menu
includeLibs.tx_mylanguage_menu = fileadmin/template/scripts/class.tx_mylanguage_menu.php
temp.menu4.30 = TEXT
temp.menu4.30 {
value = English
typolink.parameter.data = TSFE:id
# LS is langue switch Variable needed for switching the language!!!
# see realurl configuration for details
typolink.additionalParams = &LS=1&L=1
# still needed to set the domainname accordingly!!
typolink.userFunc = tx_mylanguage_menu->main
wrap = |
}
PHP:
class tx_mylanguage_menu {
function main($content) {
$tag = ‘‘;
return $tag;
}
}
Am 7. Mai 2009 um 20:29 Uhr
hmpf, das Wordpress frisst meine PHP-Funktion, ich versuchs mal so:
class tx_mylanguage_menu {
function main($content) {
# debug($content, ‘content’);
$tag = ‘<a ‘.($content[aTagParams]?$content[aTagParams].’ ‘:”);
$tag .= ($content[targetParams]?’target=”‘.$content[targetParams].’” ‘:”);
$languageSearch[] = ‘/^de\/(.*)/i’;
$DomainReplacement[] = ‘http://www.domain.de/$1′;
$languageSearch[] = ‘/^en\/(.*)/i’;
$DomainReplacement[] = ‘http://www.domain.com/$1′;
$url = preg_replace($languageSearch,$DomainReplacement,$content[url]);
$tag .= ‘href=”‘.$url.’”>’;
# debug($tag,’tag’);
return $tag;
}
Am 7. Mai 2009 um 20:30 Uhr
besser… das debug kann natürlich raus…
Viel Erfolg!
Am 15. Juni 2009 um 17:11 Uhr
Hallo zusammen,
sehr interessante Anleitung! - Eine Frage: Wie würde das ganze denn ausschauen, wenn ich nur eine Domain für alle Sprachen verwende a la
Deutsch: www.domain.de/nachrichten/
Englisch: www.domain.de/news/
Bin für alle Vorschläge dankbar.
Grüße
Pete
Am 15. Juni 2009 um 18:55 Uhr
Hallo Pete! Ohne Domain bzw. GetParameter oder Pfadsegment wie /de/ oder /en/ kann das System die auszugebene Sprache nicht ermitteln. Dazu kommt, dass sich desöfteren Begriffe überschneiden, wie z.B. “Sitemap”, wie es oft auf deutssprachigen Seiten verwendet wird.
Am 16. Juni 2009 um 12:45 Uhr
Hallo Ben,
Vielen Dank für die schnelle Antwort.
Es würde schon helfen, wenn man für die Hauptsprache (deutsch) das Pfadsegment weglassen könnte.
—
Prinzipiell ist es auch vorstellbar (für mich :) ), dass die jeweilige Sprache nur intern nach URL ermittelt/zugewiesen wird. Etwaige Doppler könnten durch (konditionales) Anhängen eines Segments (z.B. sitemap-en) vermieden werden.
Kann man etwas in der Art gegenwärtig für typo3 als nicht-Programmierer realisieren?
Grüße
Pete
Am 16. Juni 2009 um 13:06 Uhr
Sorry, da bin ich gerade überfragt und mir fehlt die Zeit mich näher damit auseinander zu setzen. Ich regle sowas grundsätzlich über Subdomains, falls es keine eigene Domain pro Sprache geben soll, also www.domain.de und dann www.en.domain.de . So gibt es auch eine deutliche Trennung für die Suchmaschinen.
Am 25. Juni 2009 um 15:33 Uhr
vielen Dank. Mit der Config von Helmut Hummel habe ich alles genau wie gewünscht zum Laufen bekommen. Da realURL ja noch ein Bug hat mit der config von _DOMAINS ist das hier die Alternative schlechthin.
Wenns jemand nicht auf die Reihe bekommt der soll sich melden.
PS.: Das mit Sitemap.html und Sitemap.html ist doch einfach über die Domains getrennt.
www.example.com/sitemap.html
www.example.de/sitemap.html
Bringt exakt die gewünschten Ergebnisse.
Der Sprachumschalter funktioniert auch gut. Jedoch war da noch eine kleine Anpassung für mich notwendig. Ansonsten: Wirklich großes Lob!
Viele Grüße
digi