Die Lösung von Typo3 Probleme!

Das “Internet” wird jetzt immer häufiger auf kleine Displays gebracht. Diese werden zudem meist noch über einen Touchscreen bedient. Was bedeutet das für die Zukunft von Webentwickler? Gibt es neue Standarts und Dinge auf die jetzt besonders ein Auge geworfen werden muss?

Durch die Bedienung mit dem Finger ist kein Mauszeiger mehr im Fenster vorhanden. Rollover-Effekte sind somit nicht mehr realisierbar. Ausklappbare Menüs und Informormationen die mit einem Tooltip dargestellt wurden sind somit also nicht mehr realisierbar. Die Seite kann also keine kleinen Widgets mehr beinhalten die Zusatzinformationen beinhalten. Diese müssten alle mit einem Klick-Event ausgestatet werden, die wiederrum auf normalen Desktop PCs zu einer umständlichen Bedienung führen, da sich viele schon an Roll-Over Effekte gewöhnt haben. Müssen also für Touchscreens extra Javascripte geschrieben werden? Stellt sich mir nur die Frage, ob man die mit den Browserinformationen einheitlich erkennt?!

Müssen Seiten generell überdacht werden um sie auf einem kleinem Display mit Touchsreen sinnvoller anzuzeigen? Für jQuery gibt es bereits eine Bibliothek, die die Seite in Form einer App auf dem iPhone darstellt. Nur geht dadurch natürlich die Kreativität verloren, wenn man alle Seiten in dieses Standart Layout zwingt.

Es wird sich zeigen, wie sich die mobile Unterhaltenselektronik entwickeln wird. An dem neuem iPad von Apple wird man gut messen können, ob sich der Touchscreen weiter durchsetzt und alle Netbooks in Zukunft so aussehen werden. Mit dem iPhone konnte Apple bereits eine Revolution auslösen..

Ich bin kein großer Fan Dreamweaver und allen anderen Programmen, die dir die Erstellung von Homepages durch ein so genannten WYSIWYG-Editor ermöglichen. Meine Abneigung kommt nicht daher, dass wirklich jeder mit einem solchen Programm eine Homepage erstellen kann und mir somit Arbeit weggenommen wird, sondern viel mehr durch schlechte Arbeitsweise dieser Programme. Ich kenne kein Programm das halbwegs sauberes HTML zaubern kann. Unendlich viele Tags stehen im Code wo eigentlich keine nötig werden, alles wird über Tabellen gelöst, CSS-Klassen kennen die Programme auch nur in den seltesten Fällen.

Vor kurzem war es mal wieder so weit: Ich sollte eine solche Homepage überarbeiten, mit mehr Funktionalität bestücken und einfach mal ein bisschen aufräumen. Die Seite wurde mit Dreamweaver erstellt, von einem Designer, der zwar vielleicht ein recht schickes Design gebastelt hat, aber null Ahnung von HTML+CSS hatte. Also wurde schön in Photoshop gesliced und in Dreamweaver irgendwie alles zurecht gerückt. Dadurch ergab sich natürlich ein durcheinander an Bildern (auch Spacer…) und vielen verwirrenden Tags. Als ich die Seite dann auch mal im Safari geöffnet habe, habe ich noch ein weiteres Problem erkennen können:

Massagessel und merkwürdige Scrollbalken

So kann man natürlich keine Massagesessel im Web bewerben, auch wenn nur ein Bruchteil der Benutzer mit dem Safari auf die Seite gesurft sind. Auch wenn die Mac-User vom eigenen Betriebssystem eh schon mit kleinen grafischen Spielereien verwöhnt sind, ist es doch zuviel des Gutens, dass man jedes einzelne Bild der Massagestühle noch nach links und rechts scrollen kann!

Also ein Typo3 aufgesetzt, Layout neu erstellt mit DIVs und CSS-Klassen und einmal alles neu gemacht. Unglaublich wie viel Arbeit das macht, obwohl man ja schon alles vorgegeben hat. Dann mussten natürlich noch alle Links umgestellt werden, da ich mir jetzt eine vernünftige Linkstruktur ausgedacht habe und die einzelnen Massagesessel-Seiten nicht mehr “massagesessel03.html” etc. heißen sollten. Das Formular musste neu Programmiert werden, da ich den Dreamweaver Javascript-Code auch nicht übernehmen wollte. Alles in allem habe ich festgestellt, das eine Überarbeitung einer Seite mehr Arbeit sein kann, als die komplette Neuerstellung! Man stößt auf viele Probleme und am Ende sieht man noch nicht mal die großen Veränderungen, gut wir haben jetzt eine englische Seite, das Layout und das Menü sind auf jeder Seite komplett gleich aufgebaut und ich kann über Typo3 schnell die Seite bearbeiten, aber trotzdem ist das Ergebnis für die Webprogrammierer-Seele ehr unbefriedigend. Ich werde wohl mal ernsthaft darüber nachdenken müssen, mir auch so ein Massagesessel für die Entspannung zu besorgen

Die Entwickler von Typo3 sind natürlich alle fleißig am Arbeiten um Bugfixe und neue Features für das umfangreiche CMS zu erstellen. Auf der User eXperience Week wurde jetzt bereits ein kleiner Einblick in die kommenden Updates von Typo3 gegeben.

Alle Probleme die jetzt in der Aktuellen Version 4.1 bekannt sind, werden vorraussichtlich in dem kommenden Update 4.2 behoben. Außerdem wird das Frontend Editing aus dem Core von Typo3 entfernt und als Extensions in Repository eingefügt. Vorteil hierbei ist, dass Updates und Bugfixe so schneller über das Repository  zur Verfügung gestellt werden können. Eine kurze Frage am Rande, nutzt ihr das Frontend Editing? Ich selber habe es noch nie benutzt und finde es praktischer alles im Backend zu machen, dann weiß man auch genauer was man macht!

Das Update 4.3 wird hingegeb wesentlich interessanter und man wird Veränderungen auch sehen können. Das gesamte Backend soll nämlich überarbeitet werden und überflüssige Funktionen entfernt werden. Dadurch soll alles ein wenig übersichtlicher werden und das Arbeiten mit Typo3 vereinfacht werden. Die gesamte Crew wurde in 5 Teams für dieses Update aufgeteilt. Jedes Team arbeitet an anderen Veränderungen beim Update. Team 4 arbeitet zum Beispiel an einer neuen Pagetree-Ansicht um die aktuellen 15 verschiedenen Pagetrees durch einen einzigen ersetzen zu können. Für Einsteiger ist die Arbeit des Team 2 sehr interessant. Diese arbeiten an einem Package, das die Bedienung und Installation für Einsteiger erleichtern soll.

Das Update 4.2 soll noch im November erscheinen, ein genauer Termin für das Update 4.3 ist noch nicht weiter bekannt.

Typolight Logo

Vor kurzem hat ein Kunde angefragt, ob er bei mir auch eine Homepage mit dem CMS Typolight bekommen könnte. Er hat dieses bereits bei einer anderen Homepage benutzt und fand es im Vergleich zu Typo3 sehr einfach zu bedienen. Also habe ich mich mal hingesetzt und versucht auch mit diesem CMS zurecht zukommen. Mein Fazit vorneweg: Typolight ist super einfach in der Bedienung, Installation und Template-Erstellung. Jedoch macht es Typo3 auf keinen Fall nutzlos!

Typolight hat von Haus aus ein Newssystem, Kalender, Formulargenerator, Dateimanager und vieles mehr integriert, schreibt die URL automatisch um, hat ein RTE der nicht erst groß konfiguriert werden muss und einfach funktioniert (!!! Der RTE von Typo3 ist sehr anstrengend wie ich finde) und natürlich Benutzerverwaltung mit Rechten. Die Installation dieser ganzen Sachen auf der Homepage ist wirklich einfach und meist mit ein paar Klicks getan. Das Newssystem zum Beispiel ist ganz einfach aus dem Hauptmenü im Backend auswählbar und man muss nicht noch erst in Listen wie in Typo3 herumklicken um über Neuigkeiten zu berichten. Im Vergleich punktet Typolight also vorallem bei der Benutzerfreundlichkeit. Aber das hat auch Nachteile. Typo3 bietet besonders durch Typoscript die Möglichkeiten, fast alle Aspekte des CMS anzupassen, hier ist Typolight nicht so ausgereift. Bei großen Datenmengen und gößeren Seiten wie Portalen oder Nachrichtenseiten würde ich zudem befürchten, dass Typolight schnell unübersichtlich wird und vollgestopft.

Trotzdem werde ich Typolight gerne in mein Angebot aufnehmen. Die stärke vo Typolight liegt aus meiner Sicht in der einfachkeit und das alles was man für eine einfache Firmenseite braucht schon in dem System integriert ist. Im Vergleich zu Typo3 ist das ein großer Vorteil. In Zukunft werde ich also kleine Firmenhomepages die nicht viel zusätzliche Programmierung brauchen immer auf Basis von Typolight erstellen. Sobald es aber komplex wird, werde ich zu Typo3 greifen da ich hier mittlerweile auch fitter mit dem inneren Ablauf des CMS und auch Typoscript bin!

Ich bin nun schon seit knapp einem Jahr Besitzer eines MacBook Pro und auch ziemlich zufrieden. Der Umstieg von PC auf den Mac ging auch recht einfach und mittlerweile arbeite ich recht schenll mit verschiedenen Fenstern dank Spaces, Expose und Spotlight. Nur der Mangel an bestimmten Programmen die ich unter Windows gewöhnt war und jetzt unter Mac nicht mehr benutzen kann hat am Anfang meine Freude noch gedämpft. Aber mittlerweile habe ich für so ziemlich alles eine passende Alternative gefunden!

Heute bin ich jedoch durch Zufall auf ein komisches Verhalten des Docks gestossen. Ich habe ein paar Ordner ganz rechts im Docks platziert, sodass ich immer schnell auf diese zugreifen kann. Also vorhin mit gleichzeitig gedrückter Umschalt-Taste auf den Ordner geklickt hab, bot sich mir ein merkwürdiges Bild. Denn in aller Ruhe konnte ich beobachten, wie sich der Ordner ausklappt. Irgendwie scheint dort ein Zeitlupemodus integriert zu sein, der sich eben mit dieser Tastenkombination ausführen lässt! Feature oder Bug? So richtig Sinn nutzen kann ich daraus nicht ziehen, daher wohl ehr ein Bug, trotzdem aber lustig anzusehen.

Es gibt bereits viele Möglichkeiten im Web um Duplicate Entry durch das weglassen von www. zu vermeiden. Häufig sind Seiten sowohl mit als auch ohne das www vor der URL zu erreichen, die weiteren Verlinkungen gehen dann zwar meist einheitlich auf eine Methode über, aber trotzdem ist es eine unschöne und Suchmachinen-technisch unsaubere Lösung beides zuzulassen. Auch für Typo3 gibt es Lösungen für das Problem. Man kann zum Beispiel ein Domain Eintrag auf der obersten Seite der Homepage erstellen und dem Sagen, dass er auf die Domain mit www.-Weiterleiten soll. Soviel zur Theorie, bei mir hat die Lösung nicht gut geklappt und es kam häufig zu redirect loops. Falls man jedoch doch diese Methode wählen sollte, sollte man aufjedenfall dieses Plugin benutzen, da ein 301 redirect für Suchmachinen in diesem Fall optimal ist.

Nochmal zur Erinnerung, 301 redirects sagen Google und Co, dass sie die weitergeleitete Seite in Zukunft immer auf der neuen Adresse suchen sollen. Dadurch wird der Page Rank auf die neue Seite vererbt und die Suchmachinen denken nicht, dass zwei mal die selbe Seite mit selben Inhalt existiert, also Duplicate Entry.

Nun also zu meiner Lösung. Wie bereits in meinem letzten Beitrag benutze ich die Möglichkeit im Typoscript eine PHP-Datei auszuführen. Um von Seiten ohne www auf Seiten mit zu verlinken, überprüfe ich ob die aktuell aufgerufene URL das www am Anfang enthält. Ist dieses nicht vorhanden, mache ich einen 301 redirect auf die selbe Seite, füge jedoch am Anfang das www mit an. Eine wie ich finde absolut einfache Lösung, ohne die htaccess Datei zu bearbeiten oder Extensions installieren zu müssen. Im folgenden der PHP-Quelltext der ausgeführt werden muss um dies zu tun.

if (strpos($_SERVER['SCRIPT_URI'],’www.’) === FALSE) {
header(‘HTTP/1.1 301 Moved Permanently’);
header(‘Location: http://’.$this->correctDomain.$_SERVER['SCRIPT_URL']); //$this->correctDomain -> z.B. www.typo3-problem.com
header(‘Connection: close’);
exit();
}

Es gibt in Typo3 viele Möglichkeiten das Template und die gesamte Seite zu erweitern und anzupassen. Es gibt Extensions, Typoscript und dann die Möglichkeit, Funktionen einer Klasse aus einer PHP-Datei direkt aus dem Typoscript auszuführen, durch das USER oder INT_USER Objekt. Mit diesen konnte ich nun eine mehrsprachige Typo3-Seite erfolgreich erweitern. Das Ziel war, die Spracheinstellung vom Browser zu lesen und den Benutzer auf die entsprechende Sprache der Seite weiter zu leiten. Dies soll aber nur passieren, wenn der Benutzer auf der Root-Seite landet. Um also eine entsprechende PHP-Klasse im Template einzubinden benutzt man folgendes Typoscript im Template-Setup:

// Zunächst die PHP-Datei laden
includeLibs.lang_redirect = fileadmin/libs/lang_redirect.php

// Dann die userFunction ausführen, dies geschieht im PAGE-Objekt
seite.1 = USER_INT
seite.1.userFunc = user_301redirect->user_main

Dann fehlt natürlich nur noch die entsprechende lang_redirect.php Datei. Diese beinhaltet eine Funktion, die die Sprache des Browsers überprüft und eine Funktion, die die überprüft, ob der Zugriff auf die Seite durch einen Robot geschieht. Aus Gründen der Suchmachinenoptimierung wende ich diese Methode bei Robots nicht an, sondern geb direkt die Seite aus die angefragt wurde. Im Folgenden meine PHP-Datei.

class user_301redirect {

var $correctDomain = ‘www.domain.com’; // default domain
var $languages = array(‘en’,'de’); // L=0 => en, L=1 => de (Attention: the first is default if no defined language could be read!)
var $languageForRobots = ‘de’; // language for visiting robot
var $index2html = 0; // domain.de/page/index.html => domain.de/page.html redirect
var $debugmode = 0; // enable or disable debugmode (redirect or only print of the new url)

// Main function for 301 redirect of old or wrong URIs
function user_main($content=”, $conf=array()) {
// config
$newurl = ”;
if (($_SERVER['SCRIPT_URL'] == ” || $_SERVER['SCRIPT_URL'] == ‘/’) && strpos($_SERVER['HTTP_REFERER'],’http://’.$this->correctDomain) !== 0 && $this->checkRobot == ”) { // only if no manual domain like www.conject.com/index.php?id=3

$newurl = $this->lang_getfrombrowser($this->languages, $this->languages[0], null, false, $this->languageForRobots); // add correct domain (with language variable

if (!empty($newurl)) { // only if set
// redirect to new domain via 301
header(‘HTTP/1.1 302 Found’);
header(‘Location: http://’.$this->correctDomain.’/’.$newurl);
header(‘Connection: close’);
exit();
}

}

return false; // always return nothing

}

// Function lang_getfrombrowser() gets the language variable
function lang_getfrombrowser ($allowed_languages, $default_language, $lang_variable = null, $strict_mode = true, $lang_robot = ‘de’) {

//if ($this->checkRobot() == false) { // no robot is visiting

// use $_SERVER['HTTP_ACCEPT_LANGUAGE'] if no lang variable
if ($lang_variable === null) {
$lang_variable = $_SERVER['HTTP_ACCEPT_LANGUAGE'];
}

// are there any information
if (empty($lang_variable)) {
// NO? => use default lang
return $default_language;
}

// Split header
$accepted_languages = preg_split(‘/,\s*/’, $lang_variable);

// Default values
$current_lang = ”;
$current_q = 0;

// One loop for every lang
foreach ($accepted_languages as $accepted_language) {
// Get all infos about lang
$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);

// Sytax correct
if (!$res) {
// No – so ignore
continue;
}

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

// Wurde eine Qualität mitgegeben?
if (isset($matches[2])) {
// die Qualität benutzen
$lang_quality = (float)$matches[2];
} else {
// Kompabilitätsmodus: Qualität 1 annehmen
$lang_quality = 1.0;
}

// Bis der Sprachcode leer ist…
while (count ($lang_code)) {
// mal sehen, ob der Sprachcode angeboten wird
if (in_array (strtolower (join (‘-’, $lang_code)), $allowed_languages)) {
// Check quality
if ($lang_quality > $current_q) {
// use this lang
$l = strtolower(join (‘-’, $lang_code));
if ($l == $default_language)
$current_lang = ”;
else
$current_lang = $l;
$current_q = $lang_quality;
// Stop while loop
break;
}
}

// Don’t minimalize language if in strict mode
if ($strict_mode) {
// stop while loop
break;
}

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

//} else { // if robot is visiting
// $current_lang = $lang_robot; // robot language
//}

return $current_lang;
}

// Function checkRobot() checks if visiter is a robot
function checkRobot() {
$trackUserAgent = strtolower($_SERVER['HTTP_USER_AGENT']);

if (stristr($trackUserAgent ,”archiver”)) $trackrobot = “Alexa”;
if (stristr($trackUserAgent ,”exabot”)) $trackrobot = “Exalead”;
if (stristr($trackUserAgent ,”fast”)) $trackrobot = “Fast”;
if (stristr($trackUserAgent ,”firefly”)) $trackrobot = “Fireball”;
if (stristr($trackUserAgent ,”googlebot”)) $trackrobot = “Google”;
if (stristr($trackUserAgent ,”msnbot”)) $trackrobot = “MSN”;
if (stristr($trackUserAgent ,”architextspider”)) $trackrobot = “Excite”;
if (stristr($trackUserAgent ,”scooter”)) $trackrobot = “Altavista”;
if (stristr($trackUserAgent ,”lycos_spider”)) $trackrobot = “Lycos”;
if (stristr($trackUserAgent ,”slurp”)) $trackrobot = “Yahoo”;

/* Own entries */
if (stristr($trackUserAgent ,”nagios”)) $trackrobot = “Nagios”;
if (stristr($trackUserAgent ,”robot”)) $trackrobot = “Robot”;
if (stristr($trackUserAgent ,”crawl”)) $trackrobot = “Crawler”;
if (stristr($trackUserAgent ,”gigabot”)) $trackrobot = “GigaBot”;
if (stristr($trackUserAgent ,”echo!”)) $trackrobot = “EchO!”;
if (stristr($trackUserAgent ,”baiduspider”)) $trackrobot = “BaiDuSpider”;
if (stristr($trackUserAgent ,”askjeeves”)) $trackrobot = “AskJeeves”;
if (stristr($trackUserAgent ,”turnitin”)) $trackrobot = “Turn It In”;
if (stristr($trackUserAgent ,”speedyspider”)) $trackrobot = “Speedy Spider”;
if (stristr($trackUserAgent ,”bot/”)) $trackrobot = “Bot”;
if (stristr($trackUserAgent ,”bot-”)) $trackrobot = “Bot”;
if (stristr($trackUserAgent ,”psbot”)) $trackrobot = “PS Bot”;
if (stristr($trackUserAgent ,”thepythonrobot”)) $trackrobot = “The Python Robot”;
if (stristr($trackUserAgent ,”voila”)) $trackrobot = “Voila”;
if (stristr($trackUserAgent ,”bspider”)) $trackrobot = “BSpider”;
if (stristr($trackUserAgent ,”surveybot”)) $trackrobot = “SurveyBot”;
if (stristr($trackUserAgent ,”grub.org”)) $trackrobot = “Grub.org”;
if (stristr($trackUserAgent ,”alexa”)) $trackrobot = “Alexa”;
if (stristr($trackUserAgent ,”arks”)) $trackrobot = “Arks”;
if (stristr($trackUserAgent ,”spider”)) $trackrobot = “Spider”;
if (stristr($trackUserAgent ,”yandex”)) $trackrobot = “Yandex bot”;
if (stristr($trackUserAgent ,”holmes”)) $trackrobot = “Holmes”;
/* Own entries end */

if ($trackrobot != “”) {
return $trackrobot;
} else {
return ”;
}
}

}

Bei einem Typo3-Projekt an dem ich gerade arbeite gibt es ein Content Element, welches auf manchen Seiten immer genau gleich auftaucht. Bei einer Änderung an diesem Element hätte ich in jeder Seite dieses Element bearbeiten müssen. Ich wollte dieses Element aber auch nicht fest mit Typoscript im Template verankern, oder jeweils mit einem extension template einfügen. Deshalb habe ich jetzt eine kleine aber feine Typo3 Extension programmiert, bei der man angeben kann, welches Content Element an dieser Stelle ausgegeben werden soll. Sozusagen eine Instanz darstellt. Diese Extension ist als pq_contentinstance im Typo3-Repository zu finden.
Einfach installieren und dann auf der jeweiligen Seite als Plugin einfügen und in den Plugineinstellungen, das Content Element auswählen und man hat eine Instanz!

Es gibt jedoch noch ein Problem. Momentan lade ich den Bodytext direkt aus dem tt_content eintrag aus der Datenbank. Ich habe es nicht hinbekommen, den Inhalt über das CONTENT-Objekt zu laden. Vielleicht kann mir einer helfen und sagen warum und wie das mit Typoscript besser geht. Folgendes habe ich versucht.

$cObj = t3lib_div::makeInstance(“tslib_cObj”);
$conf = array(‘table’ => ‘tt_content’,
’select.’ => array(‘where’ => ‘uid=’.$contentId),
‘pidInList’ => ”);
$renderedContent = $cObj->CONTENT($conf);

Neuen Datensatz anlegen

Man könnte denken, dass mehrere Sprachen in Typo3 einfach zu verwenden sind. Es ist ja schon vorgesorgt wurden und prinzipiell auch alles vorhanden um Sprechen in Typo3 zu verwenden. Aber es bedarf noch einiger Anpassungen, bevor alle Verlinkungen richtig gesetzt sind und die Seiten richtig angezeigt werden. Hier mal ein kleines Tutorial zu all den Sachen die man beachten muss, wenn man Typo3 auf Mehrsprachigkeit trimmen will!

Zunächst sollte man auf der ROOT-Seite eine neue Sprache im Listen-Modul anlegen. Das sollte alles sehr einfach funktionieren und erklärt sich auch fast von selbst. Wenn der Schritt getan ist, folgt die ganze Konfiguration. Die in Typo3 natürlich über Typoscript geregelt wird. Im Template arbeitet man hier für am besten mit einer Weiche und ein paar temporären Variablen. Man erstellt also eine temporäre Variable und weißt dieser einen Standartwert für die Default-Sprache zu. In der Weiche, die nur bei einer bestimmten Sprache aufgerufen wird, ersetzt man dann die Werte in der temporären Variablen. Somit ist sichergestellt, das in der Variable auch nur das drinsteht, was für die Sprache relevant ist. Diese Variable wird dann im weiteren Typoscript der eigentlichen Variable übergeben. Hier ein Beispiel:

#temporäre Variablen
temp.langParam = TEXT
temp.langName = TEXT

#Hauptsprache
config {
sys_language_uid = 0
language = en
locale_all = en_US
}
temp.langParam.value = &L=0
temp.langName.value = englisch

#2. Sprache
#Die “1″ muss mit der ID der zusatz Sprache übereinstimmen
[globalVar = GP:L = 2]
config {
sys_language_uid = 2
language = de
locale_all = de_DE
}
temp.langParam.value = &L=2
temp.langName.value = deutsch
[GLOBAL]

Hier wird nun also in die temporären Variablen langParam und langName ein Sprachen abhängiger Wert übergeben den man später dann weiter verwenden kann. config.sys_language_uid ist im übrigen auch sehr wichtig, da dieser Wert den anderen Objekten von Typo3 (z.B. tt_content und page) mitteilt, welche Sprache sie laden müssen.

Um nun ein Menu zur Auswahl der Sprache zu erzeugen, muss man wieder eine temporäre Variable einfügen. Diese Variable legt man so an, dass sie gleich in das Template an einer Markerstelle eingefügt werden kann. Folgendes Typoscript benutze ich dafür.

temp.langlink = COA
temp.langlink {
10 = TEXT
10.value = <img src=”fileadmin/templates/kite/img/flag_de.png” alt=”deutsch” />
10.typolink.parameter.data = page:uid
10.typolink.additionalParams = &L=1
10.typolink.ATagParams = lang=de xml:lang=de

20 = TEXT
20.value = <img src=”fileadmin/templates/kite/img/flag_eng.png” alt=”english” />
20.typolink.parameter.data = page:uid
20.typolink.additionalParams = &L=0
20.typolink.ATagParams = lang=en xml:lang=en
}

Durch das COA das für die Variable temp.langLink benutzt wird, können mehrere TEXT Objekte zugewiesen werden. Ich benutze in dem Fall Grafiken um auf die Sprachen zu verlinken. Diese Grafiken werden per  .value an das TEXT Objekt übergebe, um den Link zu erzeugen, benutze ich die typolink Funktion. Als Parameter übergeb ich die UID der aufgerufenen Seite (page:uid) und als adiditionalParams sag ich durch &L=1 die Sprache in der die Seite angezeigt werden soll. Dabei muss die Zahl mit der UID der in Typo3 angelegten Sprache übereinstimmen. So ist sichergestellt, dass bei klick die selbe Seite aufgerufen wird, nur in der entsprechenden Sprache.

Weitere Tips mit der Typo3 Mehrsprachigkeit werde ich hier noch veröffentlich. Das reicht erstmal als Einleitung