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