Von v12 direkt auf v14: Warum ein KI-gestützter Port des l10nmgr kein Spaziergang war

„Schmeiß den Code der alten Extension einfach in ChatGPT, die macht das schon fit für TYPO3 v14!“

Diesen Satz hört man aktuell öfter. Und Spoiler vorab: Wer so an ein Upgrade komplexer Extensions herangeht, wird sein System mit Anlauf an die Wand fahren.

Wichtiger Hinweis vorweg: Ich gehöre nicht zum Entwicklerteam des Localization Manager (l10nmgr) und das hier ist kein offizielles Release. Ich habe mir lediglich die öffentlich zugängliche v12 geschnappt und sie für interne Zwecke in Eigenregie auf TYPO3 v14 portiert. Da die v13 nicht öffentlich ist, fehlte jegliche Zwischenstufe – ich musste also zwei Major-Versionen an Breaking Changes auf einmal überbrücken.

Genau bei diesem Doppel-Sprung habe ich die echten Grenzen von KI-Tools erlebt. Hier sind ein paar konkrete Beispiele aus der Praxis, warum blindes KI-Vertrauen beim Refactoring scheitert.

---

1. Das Trainingsdaten-Problem: KI liebt alte Zöpfe

Ein Sprachmodell weiß nicht, was sich im allerneuesten TYPO3-Core geändert hat – es kennt vor allem das, womit es gefüttert wurde. Und beim Sprung von v12 auf v14 halluziniert die KI mit Vorliebe veraltete Zwischenlösungen zusammen, die im v14-Core sofort einen Fatal Error werfen:

• Die alte KI-Gewohnheit: Um Übersetzungsdatensätze abzufragen, schlägt die KI gerne gewohnte Helfer wie LocalizationRepository::getRecordTranslation() vor.
• Die v14-Realität: In v14 läuft das über saubere, TCA-basierte Record-Lookups.
• Gleiches Spiel bei der Datenbank: Altes Doctrine-Handling muss explizit auf Connection::createSchemaManager() umgebaut werden.

Die KI baut dir fehlerfreien PHP-Code – der auf einem v14-System trotzdem augenblicklich crasht, weil die Methoden im Core gar nicht mehr existieren.

---

2. Datenkorruption verhindern: Der RTE-CAT-XML-Roundtrip

Der l10nmgr schubst nicht nur ein paar Strings durch die Gegend, sondern exportiert Datenstrukturen in spezielles XML für Übersetzungs-Tools (CAT-Software) und liest sie wieder ein.

Das muss absolut symmetrisch laufen. Bei Rich-Text-Feldern (RTE) in pages und tt_content bedeutet das: Absätze, HTML-Tags und Links müssen nach dem Re-Import exakt an der gleichen Stelle sitzen wie vorher.

• Wo die KI blind ist: KI schaut auf isolierte Code-Schnipsel. Sie "sieht" nicht den gesamten Datenfluss über Export und Import hinweg. Ändert sie beim Refactoring des XML-Parsers auch nur eine Kleinigkeit, geht der Export zwar durch, aber beim Import zerschießt es leise die Formatierung in der Datenbank.
• Der FlexForm-Fallstrick: Beim Traversieren von FlexForms über das compiled TcaSchema müssen unvollständige Datensätze sauber auf null-Werte geprüft werden. Die KI vergisst solche Edge Cases gerne – bis im Backend ein Redakteur ein halb ausgefülltes Element übersetzen will und das Modul abbricht.

Solche Fehler findet keine KI per Prompting, sondern nur der Entwickler durch akribisches Debugging mit echten Testdaten.

---

3. Strikte Security: Das Desaster mit Inline-JavaScript

Ein Klassiker, wenn man die KI bittet, das Backend-Modul auf den neuesten Stand zu bringen: Sie baut schnell ein kleines Inline-Script oder ein onclick="document.forms[0].submit()" ein, damit die Buttons im Modul wieder reagieren.

In TYPO3 v14 knallt das sofort. Dank strenger Content Security Policy (CSP) sperrt der Core Inline-Code rigoros aus.

• CSP-Konformität: Sämtliche Event-Listener und Formular-Submits mussten sauber aus dem Fluid-Code getrennt und CSP-konform eingebunden werden.
• UI-Upgrade: Nebenbei musste die Navigation des Moduls auf moderne Bootstrap-5-Tabs umgestellt werden.

Der KI ist eine CSP-Violation völlig egal – in ihrer isolierten Code-Welt funktioniert das Skript ja. Dass der Browser die Ausführung im TYPO3-Backend blockiert, merkt man erst beim manuellen Testen in den Developer Tools.

---

Mein Fazit für die Praxis

Der l10nmgr läuft bei mir intern für pages und tt_content jetzt stabil unter TYPO3 v14 – aber nicht, weil die KI den Job erledigt hat, sondern weil sie mir die stupide Tipparbeit abgenommen hat, während ich den Code Schritt für Schritt durchleuchtet und korrigiert habe.

Wenn du ein ähnliches internes Portierungsprojekt planst, behandle die KI wie einen sehr schnellen, aber extrem zerstreuten Junior-Entwickler:

1. Lass dir die reine Fleißarbeit abnehmen.
2. Hinterfrage jede geänderte API-Zeile.
3. Teste den Daten-Roundtrip gründlich mit echten Test-Inhalten.

Erst die Kombination aus KI-Geschwindigkeit und deiner eigenen Erfahrung führt zu einem Code, dem du deine Datenbank anvertrauen kannst.