24. November 2013

Inkonsistenzen bei der Lokalisierung von Inhalten mit TYPO3

in ExtBase/Fluid, TYPO3

Ein substantielles Enterprise-Feature von TYPO3 ist die Unterstützung von Mehrsprachigkeit in Frontend und Backend. Bei der Umsetzung von knapp 20 mehrsprachigen Internetauftritten mit TYPO3 hatte ich reichlich Gelegenheit, neben den Schmankerln auch die Ecken und Kanten der Lokalisierung kennenzulernen, die ich an verschiedener Stelle auch auf Forge gepostet habe. Nun steht mit TYPO3 6.2 der nächste LTS-Kandidat vor der Türe und die Inkonsistenzen bestehen noch immer – Anlass für mich, das Thema an prominenterer Stelle zu diskutieren in der Hoffnung, durch eine konstruktive Diskussion etwas zur Entwicklung von TYPO3 beitragen zu können.

Overlays

TYPO3 verwaltet lokalisierte Datensätze in Form von Record Overlays. Während die Übersetzungen von Seiten in einer eigenen Tabelle vorgehalten werden (pages_language_overlay), befinden sich lokalisierte Inhalte und Datensätze aus Extensions in der gleichen Tabelle wie die Defaultsprache.

Datenlieferanten

Das Holen der Daten mit dem anschließenden Overlay von Sprache und Workspace passiert im Falle von Seiten meist über das TS-Objekt HMENU, Inhaltselemente werden gewöhnlich über das cObjekt CONTENT oder RECORD geholt. Seit der Entwicklung von Extbase können Datensätze (sowohl tt_content als auch Datensätze von eigenen Extensions) alternativ über Repositories geliefert werden, die sich transparent um die Lokalisierung kümmern. Hier gibt es massive Unterschiede, was das Sprachoverlay angeht.

TCA

So könnte z.B. ein Newsdatensatz ein Datum haben, das für alle Sprachen gilt. In diesem Falle empfiehlt es sich, das Feld nur in der Defaultsprache einzublenden. Das erreicht man über das Setzen des Wertes “exclude” für das TCA-Setting “l10n_mode” des Datum-Feldes. Bei der Auflistung der Newsdatensätze im Backend stellt man fest, dass die Datumsfelder der übersetzten Datensätze leer sind. Gravierender noch ist die Tatsache, dass eine Sortierung oder Filterung nach Datum für die übersetzten Datensätze nicht mehr funktionieren, weil das Datumsfeld der übersetzten Datensätze leer ist.

Spracheinstellungen

Noch mehr Fälle entstehen durch die verschiedenen möglichen Übersetzungskonstellationen:

  • Datensatz liegt nur in Defaultsprache vor (ein- oder ausgeblendet)
  • Datensatz liegt nur in Übersetzung vor (ein- oder ausgeblendet)
  • Datensatz ist markiert als „alle Sprachen“ (ein- oder ausgeblendet)
  • Datensatz liegt in Defaultsprache und Übersetzung vor
  • Datensatz liegt in Defaultsprache und Übersetzung vor, Defaultsprache ist ausgeblendet
  • Datensatz liegt in Defaultsprache und Übersetzung vor, Übersetzung ist ausgeblendet
  • Datensatz liegt in Defaultsprache und Übersetzung vor, beide sind ausgeblendet

Record overlays und Fluid

Wer sich im TYPO3 Core schon mal die Funktionen angesehen hat, die für Sprach- und Workspaceoverlays zuständig sind, dem wird schnell klar, wie viele Schritte hier nötig sind, um alle Fälle abzudecken.
Das hat eine hässliche Nebenwirkung bei Verwendung von Fluid Pagebrowsern in Verbindung mit lokalisierten Datensätzen. Das äußerst elegante Prinzip des Pagebrowser-Widgets sieht vor, dass dem Widget zwar die Datenbankabfrage für alle Datensätze übergeben wird, letztendlich aber nur die benötigten Datensätze aus der Datenbank geholt werden. Dieser Mechanismus versagt jedoch, sobald der Pagebrowser eine Liste von Datensätzen anzeigt, die nicht alle übersetzt sind; der Pagebrowser richtet sich hier bei der Seitennavigation nach der Defaultsprache; in der Liste angezeigt werden aber nur die übersetzten Datensätze.

Hier stößt der Overlay-Mechanismus von TYPO3 wohl an eine Grenze – es lässt sich nicht mehr in einer einzigen SQL-Query herausbekommen, wie viele Ergebnisse eine Datenbankabfrage bringen wird.

Lösung?

Die einzige mir bekannte funktionierende Lösung ist die Extension Tesseract (die übrigens hervorragend dokumentiert ist und mehrfach meine Rettung bei komplexen Projekten war).
Warum mir das nicht genügt? Zum einen sollte für so ein grundlegendes Feature keine Erweiterung installiert werden müssen – gerade das ist ja einer der Punkte, warum ich TYPO3 anderen, deutlich weniger komplexen Systemen vorziehe. Zum anderen erfordert die Verwendung von Tesseract mehr Handgriffe, als für Standard-Anwendungsfälle nötig sein sollte.

Ausblick

Die Tatsache, dass die beschriebenen Schwierigkeiten seit einigen Versionen nicht behoben wurden, bringt mich zu der Frage: Wird dieses Feature seltener oder oberflächlicher benutzt, als ich denke? Oder liegt es einfach an der zugegebenermaßen hohen Komplexität der Problematik? Hattet Ihr diese oder ähnliche Schwierigkeiten auch schon? Und wenn ja: Wie habt Ihr sie bewältigt?
Schön wäre es, wenn das neue Flaggschiff TYPO3 6.2 mit einem klaren und einheitlich funktionierendem Lokalisierungskonzept ausläuft; out-of-the-box sollte TYPO3 die Sprachoverlays nachvollziehbar und vor allem einheitlich vollziehen.

Links

10 Reaktionen zu “Inkonsistenzen bei der Lokalisierung von Inhalten mit TYPO3”

Kommentare abonnieren (RSS) oder TrackBack URL

Danke für deinen Artikel, der die Grundproblematik schon sehr gut beschreibt.

Einen kleinen Mangel hat dein Artikel aber und der ist, dass du immer von Overlays sprichst. „Tragischer Weise“ ist das aber nur „die Hälfte“ der Möglichkeiten, die TYPO3 zu bieten gedenkt, denn das System kann Mehrsprachigkeit auch ohne Overlays.

Und hier wird die Sache dann auch so richtig schmutzig, denn damit steigt die Komplexität von den oben angegebenen Fällen nochmal gewaltig.

Tatsächlich ist es so, dass wir schon unzählige Stunden in Patches, Reviews und Gespräche investiert haben, um das Problem irgendwie seit 4.6 gradezubiegen. Dass Extbase nicht identisch arbeitet mit dem Core ist einerseits eine Schande, andererseits aber auch wieder sehr gut, denn man muss nicht jeden Mist nachmachen, der da seit Jahren leider herumschwirrt.

Ein ganz großes Problem dabei ist die Abwärtskompatibilität. Es scheint fast unmöglich ein neues solides Konzept zu implementieren, ohne dass dabei irgendetwas massiv kaputt geht.

Ein vielfaches Problem der Vergangenheit ist auch, dass Extensions das Overlaying und die anderen möglichen Optionen größtenteils vollkommen falsch implementieren. Die einzige mir bekannte Lösung, um wirklich ein mit dem Core konsistentes Sprachhandling in Extensions zu erhalten, ist es die Methode exec_getQuery() aus dem ContentObjectRenderer (cObj) zu verwenden. Aber auch diese hat wieder ihre Nachteile, keine Frage, aber besser als jedes selbstgestrickte Konzept ist sie allemal.
Und hier schlägt auch wieder die Abwärtskompatibilität zu. Ändert man nämlich den Core (und sei es auch nur ein kleiner Bugfix), so funktionieren alle diese selbstgestrickten Lösungen nicht mehr. Damit hat man dann einen Breaking change, obwohl man keinen wollte. Jetzt könnte man meinen, „Hey eure selbstgestrickte Lösung ist aber böse, darum dürfen wir das im Core ändern“, leider ist dem nicht so, denn diese Extensions verwenden ganz brav die API, nur eben nicht ganz richtig.

Alles in Allem alles eine Baustelle sondergleichen. Noch schlimmer, ich fürchte sogar, dass eine neue Lokalisierungs-API, die ich für höchst überfällig halte und die dann auch von Extbase genau gleich verwendbar wäre, sogar zu einem Major Blocker für Upgrades auf 6.2 LTS werden könnte.
Es würde mich natürlich freuen, wenn dem nicht so wäre.

Wenn jemand bisher gekommen ist mit dem Lesen, dann kann er noch einen Blick riskieren in diesen Patch: https://review.typo3.org/9937
Er ist nicht perfekt, läuft aber in einer der Versionen auf einem Livesystem. Die notwendigen Änderungen im Code sprechen aber eine eindeutige Sprache.

Markus K am 24. November 2013 um 13:52

Sowas konnte nicht vorher schon mal experimentell in einer der nicht LTS Versionen ausgetestet werden und die Erfahrungen gesammelt werden, statt in jeder Version seit 4,5 den Extension Manager neu zu entwickeln?

fsfsd am 24. November 2013 um 14:18

Hi,

also ich habe große Projekte mit Multi-Language und z.b. TemplaVoila bis TYPO3 4.6 sauber ohne Extbase hinbekommen.

Seit Extbase und TYPO3 4.7 und v.a. in TYPO3 6.x hakt es gewaltig mit den Enterprise-Features von TYPO3 – nameingly Workspace-Unterstützung und Lokalisierung. Hier sehe ich auch einen Hauptgrund für das schwindende Interesse der großen Kunden an TYPO3. Und: Es wird seit TYPO3 4.7 einfach nicht konsistent weiterentwickelt, es werden Teillösungen implementiert, die Regressions verursachen und sofort wieder zurückgezuckt.

Die Performance der Workspace-Preview ist shcon seit 4.5 grottenschlecht, der EM der 6.x Versionen ist total daneben und ich erkenne die Stabilität und Performance meiner alten TYPO3-Versionen (4.2-4.6) nur noch sehr vage in den neuen Releases wieder.

Ich bin jedenfalls gespannt, was TYPO3 Neos in 1-2 Jahren zu bieten haben wird und werde dann ggfls. meinen Kunden empfehlen, lieber dieses System einzusetzen, sobald es Multi-Language-faehig ist.

frank am 25. November 2013 um 18:08

Was ist eigentlich mit der Aussage gemeint, dass Extbase nicht mit Workspace-Overlays umgehen kann? Datensätze, die ich über Extbase-Repositories abhole werden im Preview-WS gezeigt, und live nicht. Welche Funktionalität fehlt dann da noch?
Ich komme mit der Repository-Funktionalität sehr gut zurecht und hole mir inzwischen auch die Daten aus der tt_content damit, um eine möglichst einheitliche Sprachhandhabung zu erreichen.

Rainer Becker am 27. November 2013 um 11:04

All diese und noch ein paar weitere Auffälligkeiten sind auch mir begegnet.

Habe für (fast) all diese Probleme relativ elegante Workarounds/“Patch“-Extensions erzeugt.. Ohne diese ist eine komfortable Verwendung in „üblichen Anwendungsfällen“ praktisch nicht möglich.

Ein sehr cooles Feature bsp:
config.sys_language_softMergeIfNotBlank,
funktioniert jedoch nur wenn config.sys_language_overlay aktiviert ist.

Aufgrund dieser Thematik habe ich kürzlich extra einen Blog aufgesetzt, weil ich dieses Thema auch aufgreifen möchte.

In Extbase ist für die Overlay-Einstellung von Datensätzen config.sys_language_mode = ’strict‘ verantwortlich, was laut Dokumentation für pages „gedacht“ ist. Auch beim cObject CONTENT spielt sys_language_mode keine Rolle.

Für mich ist dieses Thema gerade mehr als aktuell.. Würde das Thema auch gerne weiter diskutieren und ggf. zur Verbesserung beitragen…

Gruß

Patrick am 28. November 2013 um 13:31

Ich stecke in der Übersetzungsproblematik nicht so tief drin wie Rainer und ihr anderen, aber ich bin durchaus schon mal auf Situationen gestossen, wo ich für einen Workaround für die Übersetzung von ein paar lumpigen letzten Datensätzen absolut unverhältismäßig lange tüfteln musste oder die Sache gar nicht lösen konnte.
–
2 „aber“ dazu:
+ Aber … ist die Sache einfach zu komplex? JA! Und zwar nicht nur auf Code-Seite von TYPO3, sondern auch in der Realität auf Seite des Kunden – und dazu in jedem Projekt im Detail anders gelagert. Kaum einer meiner Kunden, der fremdsprachige Versionen seiner Website möchte, ist sich auch nur im Ansatz klar, wie viele Möglichkeiten und Entscheidungen es zu treffen gilt. Meine Lokalisierungen sind nie 1:1:1:1, sondern immer 12:7:2:3. Im Vergleich zur Lokalisierung von Software, ist das doch viel komplexer.
–
Wir sind gewohnt, dass sich mit TYPO3 nahezu alles lösen lässt. Muss das nicht Grenzen haben? Müssen die TYPO3-Architekten nicht mal sagen (dürfen): „Fall 1425g geht bei uns nicht (bzw. nicht mehr – und unser Versuch es in v4.x zu lösen war eine Sackgasse)“?
–
+ Aber … muss Abwärtskompatibilität denn unununbedingt sein? NEIN! Mir ist ein Update lieber, dass eine Vereinfachung bringt, als eines das neue Funktionen bringt. Und die Erwartung eines Web-Entwicklers darf nicht sein, dass er ein CMS-Update installiert und in der von ihm individuell mit dem CMS entwickelten Website sofort alles weiter funktioniert. In das CMS wurde für das Update Arbeit reingesteckt, dann muss doch logischerweise auch in das Update der Website Arbeit gesteckt werden! Mal mehr, mal weniger.
–
Der Schlüssel bei beiden Abers ist für: Die Software-Architekten, in unserem Fall die TYPO3-Core-Entwickler müssen Ihre Entscheidungen und die Gründe und die Vor- und Nachteile, die man als Website-Betreiber und Web-Entwickler vom Update hat, klar kommunizieren und evtl. auch das anfängliche Genörgele aushalten. Wenn ich bei einem Update etwas gewinne – Features oder Vereinfachung, kann ich mir vorher überlegen, ob es mir die Update-Arbeit wert ist. Wenn ich erst nach vielen Stunden Arbeit feststelle, dass das es einen Update-Blocker in meinem Projekt gibt, bin ich natürlich auch frustriert. Das gleiche gilt für die Feature-List eines CMS, wenn jemand neu beginnt.

deflektor am 29. November 2013 um 12:04

Ich stimme Dir voll und ganz zu, deflektor. Es ist klasse, dass sich in TYPO3 alles lösen lässt. Nicht so klasse ist, dass man oft auch für scheinbar simple Fälle viel Aufwand treiben muss. Ich meine, dass sich für Lokalisierungen recht gut eine Standardmechanik festlegen ließe, die out-of-the-box und standardmäßig funktionieren sollte. Die Tüftelei für abstrusere Fälle ist ja völlig akzeptabel.
Das gilt auch für andere Bereiche – hier werden vermutlich oft minderwertige Lösungen produziert, die das Image von TYPO3 ankratzen; bloß, weil die Standardkonfiguration nicht viel hergibt – man muss einfach immer herumkonfigurieren.

Rainer Becker am 29. November 2013 um 12:19

Das einzige mal, wo ich bisher Probleme hatte mit der Multilingualität war der Sprachwechsel in tt_news. Scheinbar geht die Umschaltung zwischen erster Fremdsprache zur Originalsprache auch in der Detailsicht, wenn die News ausschließlich in der ersten Fremdsprache angelegt ist ohne Originalsprache. Nur beim umgekehrten Weg kommt eine Nachricht, dass es die Nachricht in der SPrache nicht gibt. Wir mussten deshalb den Sprachumschalter in der Detailsicht ausblenden.

Thomas D. am 29. November 2013 um 17:20

Ich kann dem Autoren nur zustimmen und frage mich ebenfalls, ob die Lokalisierungsfunktionen so selten genutzt werden,

Ich vermute, viele nutzen noch TYPO3 CMS 4.x, wo ich (in Kombination mit Templa Voila) auch deutlich bessere Erfahrungen im Bereich mehrsprachiger Websites sammelte, als mit 6.x

In der Tat wurde beispielsweise der Extension-Manager in nahezu jeder der letzten Versionen massiv angepasst. Usability-Anpassungen etc. werden scheinbar sehr fokussiert, während absolute Key-Features wie Multi-Language nicht konsistent funktionieren. Ich denke, das ist sehr schade, da gerade diese Features TYPO3 zu einem Enterprise CMS machen.
Insbesondere für die LTS-Version würde ich mir konsistente und stabile Core-Funktionalitäten wünschen, insbesondere im Bereich der Lokalisierung.

Zu guter Letzt einen Dank an den Autoren für das Hinweisen auf diese akuten Problematiken.

Matthias Secker am 03. Dezember 2013 um 23:24

Momentan hole ich mir nicht nur Extension-spezifische Datensätze, sondern auch tt_content-Datensätze über ein Repository; so sind die Übersetzungseigenschaften konsistent und zu 95% so, wie ich will. Außerdem kann ich meine Templates komplett in Fluid schreiben – das finde ich am übersichtlichsten.

Rainer Becker am 05. Dezember 2013 um 08:25

Kategorien

Archiv