# WordPress mit KI übersetzen: schnell, günstig und ohne WPML-Frust – unser kompletter Workflow > URL: https://4eck-media.de/blog/wordpress-mit-ki-uebersetzen-schnell-guenstig-und-ohne-wpml-frust-unser-kompletter-workflow/ > Language: de > Description: WordPress betreibt rund 41 Prozent aller Websites weltweit. Und trotzdem gibt es im Jahr 2026 auf dem CMS Nummer eins keinen Weg, eine Website zu übersetzen, der nicht entweder Wo… --- WordPress betreibt rund 41 Prozent aller Websites weltweit. Und trotzdem gibt es im Jahr 2026 auf dem CMS Nummer eins keinen Weg, eine Website zu übersetzen, der nicht entweder Wochen kostet, ein kleines Vermögen verschlingt – oder unterwegs stillschweigend Übersetzungen verliert. Wir wissen das, weil wir alle drei Varianten durchlebt haben. Ein Artikel mit über 10.000 Wörtern, übersetzt im WPML-Editor, Häkchen gesetzt, gespeichert – und auf der Live-Seite: Deutsch. Nicht überall, das wäre ja auffindbar gewesen. Nur in 1.247 von 1.725 Feldern. Dieser Artikel ist das Protokoll, wie wir das Problem bei uns gelöst haben. Sie erfahren, warum Übersetzungen in WordPress so oft scheitern und welche WPML-Bugs uns die meisten Nerven gekostet haben. Sie sehen unsere Lösung im Detail: eine Nachrüstung von etwa 300 Zeilen Code, die Claude Code in zehn Minuten geschrieben hat, und einen Übersetzungs-Workflow, der einen 10.000-Wörter-Artikel in 3 bis 5 Minuten übersetzt, prüft und einspielt – nachweisbar vollständig. Und am Ende bekommen Sie die beiden Prompts, mit denen Sie das Ganze bei sich nachbauen können: einen für Ihren Entwickler beziehungsweise Claude Code, einen für die Übersetzungsarbeit selbst. Eines vorweg, damit die Erwartung stimmt: Das hier ist kein „KI macht alles“-Artikel. KI macht bei uns die Routine – zuverlässig, nachprüfbar und zu einem Bruchteil der bisherigen Kosten. Die Verantwortung trägt ein Prozess mit eingebauten Kontrollen. Wie der aussieht, lesen Sie jetzt. ![WordPress-Inhalte werden mit KI automatisiert in mehrere Sprachen übersetzt und geprüft](https://4eck-media.de/wp-content/uploads/2026/07/wordpress-wpml-claude-cover-safe-layout-source.avif) ## Warum Mehrsprachigkeit kein Nice-to-have mehr ist Die kurze Antwort: weil Ihre nächste Anfrage nicht mehr zwingend aus dem Nachbarort kommt, sondern aus Zürich, Wien – oder Tokio. Wer seine Website nur auf Deutsch betreibt, macht die Sprache zum Verkaufshindernis. Und zwar an einem Markt, der genau dieses Hindernis längst abgeschafft hat. ### Was hat der EU-Binnenmarkt damit zu tun? Der Binnenmarkt hat Zölle, Grenzen und Bürokratie zwischen den Mitgliedsstaaten weitgehend eingeebnet. Eine Agentur in Görlitz kann für einen Kunden in Lissabon arbeiten, ein Shop in Graz nach Helsinki liefern – rechtlich und logistisch ist das Alltag. Die letzte echte Grenze, die übrig bleibt, ist die Sprache. Wer eine Website nur in einer Sprache anbietet, zieht die Grenze wieder hoch, die der Markt gerade abgebaut hat. Der wirtschaftliche Druck ist entsprechend real: Ihre Wettbewerber sind nicht mehr die drei Anbieter im Umkreis, sondern jeder, der die Sprache des Kunden spricht. ### Woher wissen wir, dass der Markt wirklich global ist? Aus dem eigenen Posteingang. Bei uns kommen inzwischen Anfragen aus der Schweiz, aus Österreich, aus Japan, Kanada und den USA. Der Grund ist bemerkenswert: KI-Assistenten empfehlen uns, wenn jemand nach der „besten WordPress-Agentur“ fragt oder Unterstützung bei SEO, Marketing und KI-Integration sucht. Wie man in diese Empfehlungen hineinkommt, haben wir ausführlich beschrieben in unserem [GEO-Artikel](https://4eck-media.de/blog/geo-framework-ki-sichtbarkeit-empfehlungen/) – hier zählt nur die Konsequenz: Der Kunde recherchiert in seiner Sprache, sein KI-Assistent antwortet in seiner Sprache, und wenn Ihre Website dort nicht existiert, existieren Sie für diesen Kunden nicht. Das verändert die Rechnung. Früher war eine englische Version „nett für internationale Besucher“. Heute entscheidet sie darüber, ob Sie in Antwortmaschinen überhaupt vorkommen. Und niemand kann mehr vorhersagen, in welcher Sprache die nächste Anfrage eintrifft – bei uns war es zuletzt Japanisch. Wir haben daraus die Konsequenz gezogen und in WPML zehn Sprachen angelegt. Nicht, weil wir in zehn Märkten Büros eröffnen wollen, sondern weil wir nicht mehr entscheiden können, wo der nächste Kunde recherchiert. ### Warum sind Preis und Tempo eine strategische Frage? Weil Mehrsprachigkeit kein einmaliges Projekt ist, sondern ein Dauerzustand. Jeder neue Blogartikel, jede Referenz, jede Leistungsseite muss nachgezogen werden – sonst zerfällt die fremdsprachige Version zur Ruine mit veralteten Inhalten. Und hier trennt sich die Absichtserklärung von der Praxis: Wenn eine Übersetzungsrunde Wochen dauert oder pro Sprache vierstellig kostet, unterbleibt sie irgendwann. Nicht aus bösem Willen, sondern weil im Tagesgeschäft immer etwas Dringenderes wartet. Genau deshalb behandeln wir Übersetzungskosten und Übersetzungsgeschwindigkeit nicht als operatives Detail, sondern als strategische Stellgröße: Sie bestimmen, ob Mehrsprachigkeit gelebt wird oder auf der „irgendwann mal“-Liste verstaubt. Wie wir beides in den Griff bekommen haben, zeigen die folgenden Kapitel. Warum der Markt nicht mehr lokal ist - Der EU-Binnenmarkt hat fast alle Grenzen abgebaut – Sprache ist die letzte, und sie steht auf Ihrer Website - Unsere Anfragen kommen inzwischen aus der Schweiz, Österreich, Japan, Kanada und den USA - KI-Assistenten empfehlen uns auf Anfragen wie „beste WordPress-Agentur“ sowie zu SEO, Marketing und KI-Integration - Wer nur eine Sprache anbietet, ist in fremdsprachigen KI-Antworten schlicht nicht vorhanden - Preis und Geschwindigkeit von Übersetzungen entscheiden, ob Mehrsprachigkeit dauerhaft gepflegt wird ### Häufige Fragen zur Mehrsprachigkeit Lohnt sich Mehrsprachigkeit auch für kleine Unternehmen? Gerade dann. Große Anbieter leisten sich Übersetzungsbüros, kleine verlieren internationale Anfragen kampflos. Wenn Übersetzungen schnell und günstig werden, verschwindet das einzige rationale Argument dagegen – und der adressierbare Markt wächst, ohne dass Sie eine einzige Anzeige schalten. Mit welcher Sprache sollte man anfangen? Mit der, aus der bereits Anfragen kommen oder in der Ihre Zielkunden recherchieren. Englisch ist meist der erste Schritt, weil es auch von KI-Assistenten als Brückensprache genutzt wird. Danach entscheidet Ihr Markt, nicht das Bauchgefühl. Reicht nicht der automatische Übersetzer im Browser des Besuchers? Nein. Browser-Übersetzung greift erst, wenn der Besucher schon auf Ihrer Seite ist. Der entscheidende Moment liegt davor: in der Suche und in der KI-Empfehlung, die in der Sprache des Nutzers stattfindet. Dort zählt nur, was tatsächlich übersetzt auf Ihrer Domain liegt. ## Wie Übersetzungen in WordPress funktionieren – und woran sie scheitern Wenn Sie verstehen wollen, warum Website-Übersetzungen so mühsam und teuer sind, brauchen Sie nur eine einzige Einsicht: WordPress speichert einen Artikel nicht als einen Text. Es speichert ihn als Hunderte kleiner Felder – und jedes einzelne davon muss durch die Übersetzung. ### Warum ist ein Artikel kein „ein Text“? Was im Browser wie ein durchgehender Artikel aussieht, liegt in der Datenbank zerlegt vor: die Überschrift ist ein Feld, jeder Absatz ist ein Feld, jeder einzelne Listenpunkt, jede Bildunterschrift, jede Zwischenüberschrift. Dazu kommen die unsichtbaren Teile, die kein Besucher liest, aber jede Suchmaschine: SEO-Titel, Meta-Beschreibung, der URL-Slug. Ein konkretes Beispiel aus unserem eigenen Blog: Unser größter Artikel, das GEO-Framework, besteht aus 1.599 Blöcken und zerfällt in 1.725 Übersetzungssegmente. Über 10.000 Wörter, verteilt auf mehr als 1.700 Formularfelder. Das ist ein Extremfall, zugegeben – aber er zeigt, in welcher Größenordnung ein einziger ambitionierter Fachartikel spielt. Übersetzungsplugins bilden genau diese Struktur ab. WPML ist der Marktführer, Polylang und TranslatePress sind die bekanntesten Alternativen – das Grundprinzip ist überall gleich: Das Plugin legt für jede Sprache eine Kopie der Feldstruktur an und führt jedes Feld einzeln durch die Übersetzung. Das ist kein Konstruktionsfehler, sondern notwendig, damit Layout, Links und Formatierung die Übersetzung überleben. Aber es erklärt, warum „übersetz mal eben die Seite“ keine kleine Bitte ist. Es gibt im Wesentlichen drei Wege, diese Felder zu füllen – und jeder tut auf seine Weise weh. ### Weg 1: Manuell im Übersetzungseditor Der Übersetzungseditor zeigt links das deutsche Feld, rechts das leere Zielfeld. Man übersetzt, klickt weiter, übersetzt, klickt weiter. Bei einer Kontaktseite mit zwanzig Feldern ist das machbar. Bei einem 10.000-Wörter-Artikel mit über 1.700 Feldern ist es tagelange Fließbandarbeit – pro Sprache, wohlgemerkt. Und es ist die anstrengendste Sorte Arbeit: monoton genug, um Fehler zu produzieren, aber zu anspruchsvoll, um sie an Ungelernte abzugeben. Wer nach Feld 900 die Konzentration verliert, merkt es nicht – das Ergebnis merkt es. Wir haben zehn Sprachen in WPML angelegt; wer diese Rechnung einmal ehrlich zu Ende denkt, legt den Taschenrechner ganz schnell wieder weg. ![WPML-Übersetzungseditor mit der langen Feldliste eines großen Artikels, viele Felder pro Beitrag](https://4eck-media.de/wp-content/uploads/2026/07/Bild-2-wpml.avif) ### Weg 2: Das Übersetzungsbüro Der klassische Weg: Text exportieren, an ein Büro geben, Ergebnis einpflegen. Qualitativ oft gut – aber die Abrechnung folgt einer unbarmherzigen Formel: Preis pro Wort × Umfang × Anzahl der Sprachen. Bei einer Website wie unserer, mit 116 Blogartikeln, 53 Referenzen und 199 Kompetenz-Seiten, wird aus dieser Multiplikation ein Betrag, den kein Marketingbudget freiwillig hergibt. Dazu kommt der Rückweg: Irgendjemand muss die gelieferten Texte wieder in die Hunderte Felder einsortieren – womit Sie einen Teil von Weg 1 gratis dazubekommen. ### Weg 3: Automatische Übersetzung mit WPML-Credits WPML bringt eine eingebaute Automatik mit: Auf Knopfdruck übersetzen DeepL, Google oder Microsoft die Inhalte, abgerechnet wird über Credits. Das ist der bequemste Weg – und er hat zwei Haken. Erstens die Abrechnung: pro Wort und pro Sprache. Einen Artikel in eine Sprache zu bringen ist billig; 116 Artikel in mehrere Sprachen zu bringen ist es nicht mehr. Wer regelmäßig publiziert, zahlt regelmäßig mit. Zweitens, und das wiegt schwerer: Die Automatik übersetzt ohne Projektkontext. Sie kennt Ihre Marke nicht, Ihre Produktnamen nicht, Ihre Terminologie nicht – sie sieht immer nur das einzelne Segment, das gerade dran ist. Also übersetzt sie Markennamen munter mit, und Fachbegriffe springen zwischen den Seiten hin und her: Auf einer Seite heißt es so, auf der nächsten anders, und der Leser fragt sich, ob das zwei verschiedene Dinge sind. Das Ergebnis ist selten falsch, aber zuverlässig mittelmäßig. Für eine Visitenkarten-Seite mag das reichen. Für einen Blog, der Kompetenz beweisen soll – und der von KI-Assistenten als Quelle herangezogen werden will -, ist „zuverlässig mittelmäßig“ das falsche Qualitätsziel. Halten wir fest: teuer, langsam oder mittelmäßig – suchen Sie sich eins aus. Genau an dieser Stelle setzt unser Workflow an. Vorher müssen wir aber noch über etwas Unangenehmeres reden: über die Stellen, an denen WPML nicht nur mühsam ist, sondern schlicht kaputt. Drei Wege – teuer, langsam oder mittelmäßig - Ein WordPress-Artikel ist kein Text, sondern Hunderte Felder: unser größter zerfällt in 1.725 Segmente bei über 10.000 Wörtern - Weg 1, manuell im Editor: über 1.700 Felder pro Sprache – tagelange Fließbandarbeit - Weg 2, Übersetzungsbüro: Preis pro Wort × Umfang × Sprachen – bei 116 Artikeln unbezahlbar - Weg 3, WPML-Credits: bequem, aber Abrechnung pro Wort und Sprache – und ohne Projektkontext werden Marken mitübersetzt - Alle drei Wege skalieren schlecht: teuer, langsam oder mittelmäßig ### Häufige Fragen zu WordPress-Übersetzungen Warum kann ich den Artikel nicht einfach komplett kopieren und übersetzt einfügen? Weil dabei die Struktur verloren geht: Blöcke, Formatierungen, interne Links und SEO-Metadaten hängen an den einzelnen Feldern. Übersetzungsplugins zerlegen den Inhalt genau deshalb in Segmente – nur so bleibt die Seite nach der Übersetzung technisch identisch mit dem Original. Ist WPML die richtige Wahl oder lieber Polylang bzw. TranslatePress? Für Websites mit komplexen Inhalten (ACF-Felder, Gutenberg-Blöcke, SEO-Metadaten) ist WPML am tiefsten integriert und deshalb Marktführer. Polylang und TranslatePress sind schlankere Alternativen für einfachere Setups. Wer schon tief in WPML steckt, sollte wissen: Eine Migration ist meist teurer als die Reparatur der Probleme. Reicht die automatische WPML-Übersetzung nicht für den Anfang? Für einzelne Seiten: ja, durchaus. Das Problem beginnt bei Menge und Anspruch – viele Artikel mal mehrere Sprachen wird teuer, und ohne Glossar und Kontext leidet die Konsistenz. Für eine Visitenkarten-Website okay, für einen Fachblog zu wenig. Wie viele Segmente hat eine normale Seite? Das schwankt enorm. Eine kurze Leistungsseite kommt mit ein paar Dutzend Feldern aus, unser größter Blogartikel bringt es auf 1.725 Segmente. Genau diese Spannbreite macht Pauschalaussagen über Übersetzungsaufwand so unzuverlässig – zählen Sie Segmente, nicht Seiten. ## Die WPML-Bugs, die wir auf die harte Tour gelernt haben Vorweg, damit kein falscher Eindruck entsteht: Wir lieben WordPress. Es betreibt rund 41 Prozent aller Websites und hält knapp 60 Prozent des CMS-Markts – wir bauen unser Geschäft darauf. Genau deshalb ärgern wir uns. Was jetzt kommt, ist keine Abrechnung von Hatern, sondern das Protokoll von Nutzern, die WPML produktiv einsetzen und dabei Dinge gefunden haben, die man in keiner Produktbeschreibung liest. ### Der stille Datenverlust: max_input_vars Der schlimmste Bug ist der, der keine Fehlermeldung wirft. Unser GEO-Framework-Artikel hat 1.599 Blöcke, die im Übersetzungseditor zu über 1.700 Formularfeldern werden. PHP hat aber eine Standardgrenze, wie viele Formularfelder ein Server pro Anfrage annimmt: max_input_vars, ab Werk 1.000. Alles darüber wird beim Speichern still verworfen. Kein Fehler, keine Warnung – der Editor meldet Erfolg, die überzähligen Felder sind einfach weg. Das Ergebnis bei uns: 1.247 von 1.725 Segmenten hingen fest. Im Editor sauber übersetzt, Häkchen „Translation is complete“ gesetzt – aber die Übersetzungen sind nie auf der Live-Seite angekommen. Man hat tagelang gearbeitet, das System bestätigt die Arbeit, und der Besucher der übersetzten Seite liest trotzdem Deutsch. Das Tückische daran: Der Fehler sieht aus wie ein Bedienfehler. Hat jemand vergessen zu speichern? Die falsche Sprache erwischt? Wer nicht weiß, wonach er suchen muss, sucht wochenlang bei sich selbst – während die Ursache eine Serverkonstante ist, von der die meisten Redakteure nie gehört haben. ### Grüne Häkchen auf leeren Feldern Noch perfider: Wir haben Übersetzungen gefunden, bei denen das Häkchen „Translation is complete“ gesetzt war – auf leeren Feldern. Der Status sagt fertig, das Feld sagt nichts. Für ein Übersetzungssystem ist das der Super-GAU, denn der Status ist das Einzige, worauf sich Planung und Abnahme stützen. Unsere Konsequenz steht seither in jeder Arbeitsanweisung: Den Status-Häkchen darf man nicht glauben. Kontrolliert wird am exportierten Inhalt, nie am Dashboard. ![WPML-Editor: mehrere leere Zielfelder mit gesetztem Häkchen „Translation is complete“ bei 1 Prozent Fortschritt](https://4eck-media.de/wp-content/uploads/2026/07/bild-03-wpml-complete-leer.avif) ### Das Translation Memory vergisst Das Translation Memory ist eigentlich WPMLs stärkstes Feature: Was einmal übersetzt wurde, wird beim nächsten Mal vorausgefüllt. Bei unserem großen Artikel lieferte es immerhin 462 von 1.725 Segmenten fertig vor – knapp ein Viertel geschenkte Arbeit, das nehmen wir gern. Aber es hat eine Schwäche: Wenn sich ein Artikel ändert und WPML die Inhalte neu segmentiert, gehen dabei Segmente verloren, die eigentlich schon übersetzt waren. Man bezahlt dieselbe Übersetzung dann ein zweites Mal – oder, schlimmer, man übersieht, dass sie fehlt, weil ja „eigentlich alles schon mal übersetzt war“. Auf ein Gedächtnis, das beim Umblättern vergisst, baut man keine Planung. ### Und dann kommt noch der Cache obendrauf Angenommen, Sie haben all das gefunden und die Korrekturen importiert. Dann sitzt zwischen Ihnen und dem Besucher noch der Seiten-Cache: In einem Fall war die Korrektur längst im System, aber Besucher sahen noch 24 Stunden lang die alte, fehlerhafte Version. Für die Qualitätskontrolle heißt das: Selbst der Blick auf die Live-Seite beweist nichts, solange man nicht weiß, wann der Cache zuletzt geleert wurde. Fehlersuche wird so zum Schichtenmodell – Editor, Datenbank, Cache, und jede Schicht kann eine andere Wahrheit erzählen. ### Der Kleinkram, der Stunden kostet Zwei Fundstücke aus der Kategorie „kostet nur Nerven“: Der Export liefert immer XML – völlig egal, welche Dateiendung man anfordert. Wer sein Tooling auf ein anderes Format aufgebaut hat, darf umbauen. Und die REST-API sieht versteckte Sprachen nicht: Solange eine Sprache noch nicht öffentlich geschaltet ist, kann man sie über die Schnittstelle schlicht nicht abfragen – ausgerechnet in der Phase, in der man am dringendsten automatisiert prüfen möchte. ### Warum wir trotzdem nicht wechseln Man könnte jetzt rufen: Weg mit WPML! Wir sehen das anders, aus zwei Gründen. Erstens ist WPML tief in unsere Website integriert – ACF, Gutenberg, SEO-Metadaten. Eine Migration wäre teurer als die Reparatur. Zweitens, und das ist der wichtigere Punkt: Unter der Haube ist alles da. XLIFF-Export und -Import, Translation Memory, interne APIs – die Maschine funktioniert. Kaputt ist nur die Browser-Formular-Ebene, also genau die Schicht, mit der Menschen arbeiten. Und halten wir fest: Das sind keine Bedienfehler. Wir haben lange genug in die andere Richtung gesucht, um das mit einiger Sicherheit zu sagen. Das sind Systemprobleme eines Tools mit über einer Million Installationen. Wenn ein Formular bei großen Artikeln still Daten verwirft und ein Status-Häkchen auf leeren Feldern steht, dann trifft das jeden, der ernsthaft mehrsprachig publiziert – die meisten merken es nur nicht, weil niemand die polnische Version des eigenen Blogs Feld für Feld gegenliest. Die gute Nachricht: Genau weil die Unterbau-Funktionen intakt sind, kann man die kaputte Formular-Ebene umgehen, statt sie zu reparieren. Wie, zeigt das nächste Kapitel. Die WPML-Fallen, die uns Nerven gekostet haben - max_input_vars (Standard: 1.000 Felder) schneidet das Editor-Formular bei großen Artikeln still ab – 1.599 Blöcke, über 1.700 Felder, keine Fehlermeldung - Folge bei uns: 1.247 von 1.725 Segmenten übersetzt und als „complete“ markiert, aber nie auf der Live-Seite angekommen - Häkchen „Translation is complete“ fanden wir auch auf komplett leeren Feldern – dem Status ist nicht zu trauen - Translation Memory verliert bei Re-Segmentierung bereits übersetzte Segmente; der Cache zeigte Besuchern 24 Stunden lang die alte Version - Kleinkram: Export liefert immer XML, die REST-API sieht versteckte Sprachen nicht - Fazit: Systemprobleme, keine Bedienfehler – aber der Unterbau (XLIFF, TM, interne APIs) funktioniert ### Häufige Fragen zu WPML-Problemen Woran erkenne ich, dass mich der max_input_vars-Bug betrifft? Am Widerspruch zwischen Status und Live-Seite: Der Editor meldet „complete“, aber auf der übersetzten Seite steht weiter deutscher Text oder Felder bleiben leer. Betroffen sind vor allem lange Artikel mit vielen Blöcken. Exportieren Sie die Übersetzung und suchen Sie im Ziel nach leeren Segmenten und Ausgangssprache – dem Häkchen allein dürfen Sie nicht glauben. Reicht es, max_input_vars auf dem Server hochzusetzen? Es entschärft diesen einen Bug, ja – sofern Ihr Hoster den Wert überhaupt ändern lässt. Die anderen Probleme bleiben: falsche Complete-Status, Segment-Verluste im Translation Memory, Cache-Verzögerungen. Wir haben uns deshalb entschieden, das Formular komplett zu umgehen und per XLIFF zu importieren – eine Operation, kein Feldlimit. Sollten wir wegen dieser Bugs von WPML weg migrieren? In den meisten Fällen: nein. Bei tiefer Integration mit ACF, Gutenberg und SEO-Metadaten ist eine Migration teurer als die Reparatur, und die Kernfunktionen von WPML sind intakt. Kaputt ist die Formular-Ebene im Browser – und die lässt sich umgehen, statt das ganze System auszutauschen. Wie stellen wir sicher, dass Übersetzungen wirklich live sind? Mit Kontrolle am Inhalt statt am Status: Übersetzung nach dem Import erneut exportieren und abgleichen, ob alles angekommen ist; auf der Live-Seite stichprobenartig nach Ausgangssprache suchen; und nach Korrekturen den Cache im Blick behalten. Bei uns ist dieser Kontroll-Export fester Bestandteil jedes Übersetzungszyklus. ## Reparieren statt wechseln: unsere Entscheidung Wir sind bei WPML geblieben – und haben stattdessen einen Weg am kaputten Formular vorbei gebaut. Diese Entscheidung fiel nicht aus Nostalgie, sondern nach einer nüchternen Rechnung: WPML steckt bei uns tief im Projekt. ACF-Felder, Gutenberg-Blöcke, SEO-Metadaten – alles läuft durch WPML, über zehn Sprachen hinweg. Eine Migration auf ein anderes Übersetzungs-Plugin hätte bedeutet, diese Verdrahtung bei 116 Blogartikeln, 53 Referenzen und 199 Kompetenz-Seiten neu aufzubauen. Das wäre teurer geworden als die Reparatur. Deutlich teurer. Dazu kam eine Beobachtung, die alles veränderte. Als wir unter die Haube geschaut haben, war da nichts kaputt. WPML hat XLIFF-Export und -Import. WPML hat ein Translation Memory, das sich jede jemals übersetzte Passage merkt. WPML hat interne APIs, die all das sauber abwickeln. Der Maschinenraum funktioniert. Kaputt ist nur die Benutzeretage: das Browser-Formular des Übersetzungseditors, das bei großen Artikeln mehr Felder abschickt, als der Server annimmt – und die überzähligen stillschweigend verwirft. Ein Plugin-Wechsel hätte also den funktionierenden Maschinenraum mit entsorgt, nur um eine defekte Oberfläche loszuwerden. Und obendrauf das Translation Memory: jede bereits bezahlte, bereits abgenommene Übersetzung aus zehn Sprachen. Dieses Kapital gibt niemand freiwillig auf. Wer wegen einer defekten Etage das ganze Haus abreißt, hat ein Budgetproblem. Die rationale Antwort lautet: Wir nehmen die Treppe. Konkret heißt das, den Zyklus aus Ausleiten, Übersetzen und Einspielen komplett am Formular vorbeizuführen – direkt über die Funktionen, die WPML ohnehin mitbringt. Kein Fork, kein Ersatz, kein Parallelbetrieb zweier Plugins. Nur eine Umleitung um die eine Stelle, die nicht trägt. Und genau hier kommt KI ins Spiel. Nicht als Zauberknopf mit der Aufschrift „übersetzen“, auf den man drückt und hofft – solche Knöpfe hatten uns ja gerade erst leere Felder mit grünen Häkchen beschert. Sondern als Arbeiter, dem man zwei sehr konkrete Aufträge übergeben kann. Erstens: die Nachrüstung selbst – den Code schreiben, der die Umleitung öffnet. Zweitens: die Übersetzung – die eigentliche Fleißarbeit, Segment für Segment, mit Prüfungen davor und danach. Beides sind Aufgaben mit klaren Regeln und messbarem Ergebnis. Genau die Sorte Arbeit, bei der KI heute zuverlässig liefert – und bei der ein Mensch als Reviewer trotzdem das letzte Wort behält. Wie diese Nachrüstung aussieht, wie lange sie wirklich gedauert hat und warum sie aus einem kaputten Editor einen durchlaufenden Übersetzungs-Workflow macht – das sind die nächsten beiden Kapitel. ## Die Nachrüstung: ein Mini-Plugin mit vier Routen, das Claude Code in zehn Minuten geschrieben hat Die ganze Reparatur ist ein einziges mu-plugin: rund 300 bis 400 Zeilen PHP, die vier HTTP-Routen zu Funktionen öffnen, die WPML längst besitzt. Das Plugin übersetzt nichts, erzeugt nichts, löscht nichts. Es ist eine Tür – mehr nicht. Den Code hat Claude Code nach einer technischen Spezifikation geschrieben, unser Entwickler hat reviewt und deployed. Die Generierung selbst war eine Zehn-Minuten-Aufgabe. ![Architektur des geo-helper Mini-Plugins: KI-Umgebung, REST-Routen, WPML-Funktionen und Datenbank](https://4eck-media.de/wp-content/uploads/2026/07/bild-04-plugin-architektur.avif) ### Was genau macht das Plugin? Es stellt fünf Endpunkte bereit, vier davon tragen die eigentliche Arbeit: - **/status** – was ist übersetzt, was nicht. Die Antwort, die man im WPML-Backend mühsam zusammenklicken müsste, als eine Abfrage. - **/requeue** – einen Inhalt neu in die Übersetzungswarteschlange stellen. WPML baut daraufhin den Job und füllt aus dem Translation Memory alles vor, was je übersetzt wurde. - **/export** – den kompletten Inhalt als XLIFF-Datei ausleiten, Segmente paarweise: deutsche Quelle, zielsprachliches Feld. - **/import** – die fertige XLIFF-Datei zurückspielen, als eine Operation. Dazu kommt **/ping** für die Diagnose: Antwortet die Installation überhaupt, bevor man einen Lauf startet? Entscheidend ist, was das Plugin *nicht* tut. Es erfindet keine neue Übersetzungslogik, keinen eigenen Editor, kein Parallel-Datenmodell. Jede Route ist ein reiner Wrapper um eine WPML-interne Funktion – dieselben Mechanismen, die auch der offizielle XLIFF-Workflow von WPML nutzt. Wir haben keinen Umbau vorgenommen, sondern vier vorhandenen Fähigkeiten eine Adresse gegeben, die man ohne Browser erreicht. ### Wie ist es entstanden? Transparent erzählt, weil genau dieser Teil viele Projektmanager interessiert: Am Anfang stand nicht Code, sondern eine technische Spezifikation – welche Routen, welche Parameter, welches Verhalten im Fehlerfall, was ausdrücklich verboten ist. Diese Spezifikation haben wir mit Claude Code erarbeitet und dann als Auftrag zurückgegeben: Schreib das mu-plugin exakt nach diesem Dokument. ![Technische Spezifikation der fünf REST-Routen des geo-helper Plugins](https://4eck-media.de/wp-content/uploads/2026/07/bild-05-spezifikation-routen.avif) Die Code-Generierung dauerte etwa zehn Minuten. Und hier bleiben wir ehrlich, weil die Zehn-Minuten-Zahl allein ein schiefes Bild malen würde: Das Review durch unseren Entwickler, das Einrichten der IP-Allowlist und das Deployment haben einen Abend gekostet. Ein Mensch hat jede Zeile gelesen, bevor sie auf die Live-Umgebung durfte. Das ist kein Misstrauen gegenüber der KI, sondern schlicht die Arbeitsteilung, die wir für jeden Code auf einer Kundenumgebung ansetzen würden – egal, wer ihn geschrieben hat. Die Rechnung geht trotzdem klar auf: ein Abend Aufwand für ein Werkzeug, das seitdem jeden Übersetzungszyklus trägt. ### Ist das sicher? Die Frage kam intern als erste, und sie ist berechtigt: Vier offene HTTP-Routen an einer Produktiv-Website klingen zunächst nach Angriffsfläche. Unsere Antwort besteht aus drei Ebenen. Erstens: eine IP-Allowlist statt Tokens. Nur die festen Ausgangs-IP-Adressen der KI-Umgebung dürfen die Routen überhaupt ansprechen; jede andere Anfrage prallt ab. Damit liegen auch keine Tokens im Code, die auslaufen, geleakt oder versehentlich committet werden könnten. Zweitens: Das Plugin kann nichts löschen. Diese Fähigkeit existiert im Code schlicht nicht – der schlimmste anzunehmende Fall ist ein fehlgeschlagener Import, kein verlorener Inhalt. Drittens: Es erzeugt keine Inhalte. Keine neuen Beiträge, keine Seiten, keine Nutzer. Es bewegt ausschließlich Übersetzungsdaten durch Kanäle, die WPML selbst definiert. ### Warum ist das der Gamechanger? Weil sich damit ändert, *wer* den Zyklus fahren kann. Vorher hing „ausleiten → übersetzen → einspielen“ am Browser: einloggen, klicken, warten – und beim Speichern großer Artikel genau in die max_input_vars-Falle laufen, die wir in den vorigen Kapiteln seziert haben. Ein KI-Agent kann kein Browser-Formular retten, das der Server serverseitig abschneidet. Mit den vier Routen läuft derselbe Zyklus ohne Browser. Und das heißt: Ein KI-Agent kann ihn komplett übernehmen. Er fragt den Status ab, stellt den Artikel neu in die Warteschlange, holt die XLIFF-Datei, übersetzt, prüft, spielt zurück und gleicht ab – und scheitert dabei nicht an einem Formular, das nie für 1.700 Felder gebaut wurde. Aus einem Werkzeug, das ein Mensch bedienen muss und das bei großen Inhalten versagt, wird eine Schnittstelle, die eine Maschine zuverlässig bedienen kann. Der nächste Abschnitt zeigt diesen Ablauf Schritt für Schritt am größten Artikel unserer Website. Das Helfer-Plugin in fünf Punkten - Ein mu-plugin, ca. 300–400 Zeilen PHP – reine Wrapper um existierende WPML-Funktionen - 4 Arbeitsrouten (/status, /requeue, /export, /import) plus /ping für die Diagnose - Code-Generierung durch Claude Code: ~10 Minuten; Review, IP-Allowlist und Deployment durch den Entwickler: ein Abend - Sicherheit: IP-Allowlist statt Tokens, kein Löschen möglich, erzeugt keine Inhalte - Effekt: Der Zyklus „ausleiten → übersetzen → einspielen“ läuft ohne Browser – ein KI-Agent kann ihn komplett übernehmen ### Häufige Fragen zur Nachrüstung Ersetzt das Mini-Plugin WPML? Nein. Es ergänzt WPML um vier von außen erreichbare Routen zu Funktionen, die WPML bereits mitbringt: XLIFF-Export, XLIFF-Import, Warteschlange, Statusabfrage. Übersetzt wird nach wie vor in WPMLs Datenstrukturen – inklusive Translation Memory. Übersetzt das Plugin selbst? Nein, keine einzige Zeile. Es leitet Inhalte als XLIFF aus und spielt fertige XLIFF-Dateien wieder ein. Die Übersetzung passiert außerhalb – bei uns durch KI-Agenten, es könnte aber genauso ein menschliches Übersetzungsbüro am anderen Ende sitzen. Warum eine IP-Allowlist und keine API-Tokens? Weil die KI-Umgebung feste Ausgangs-IP-Adressen hat und wir damit die Angriffsfläche auf ein Minimum reduzieren, ohne Geheimnisse im Code zu verwalten. Kein Token bedeutet: nichts, was ablaufen, geleakt oder versehentlich in ein Repository geraten kann. Kann so ein Plugin die Website beschädigen? Das Schadenspotenzial ist bewusst klein gehalten: Das Plugin kann keine Inhalte löschen und keine erzeugen, es bewegt nur Übersetzungsdaten über WPML-eigene Mechanismen. Dazu kommt der Kontroll-Export nach jedem Import, der prüft, ob wirklich angekommen ist, was ankommen sollte. ## So läuft eine Übersetzung heute: der Workflow Schritt für Schritt Das Ergebnis vorweg, am härtesten Beispiel unserer Website: Unser größter Artikel – das GEO-Framework, 1.725 Übersetzungssegmente, über 10.000 Wörter – wurde mit diesem Workflow in 3 bis 5 Minuten übersetzt. 1.215 Segmente frisch übersetzt, automatisch geprüft, importiert und per Kontroll-Export bestätigt. Derselbe Artikel, an dem vorher 1.247 Segmente im kaputten Editor festhingen. Hier ist der Ablauf, Schritt für Schritt. ![WPML-Übersetzungsqueue mit vielen Inhalten in mehreren Sprachen, alle im Status muss übersetzt werden](https://4eck-media.de/wp-content/uploads/2026/07/bild-10-wpml-queue.avif) ### Schritt 1: requeue – WPML deckt den Tisch Der Agent ruft die /requeue-Route auf, WPML baut den Übersetzungsjob und füllt aus dem Translation Memory alles vor, was je übersetzt wurde. Bei unserem Artikel lieferte das TM 462 von 1.725 Segmenten fertig – gut ein Viertel der Arbeit war erledigt, bevor irgendjemand ein Wort übersetzt hatte. Das ist der Moment, in dem sich jede früher gespeicherte Übersetzung auszahlt, auch die aus der WPML-Ära vor der Nachrüstung. ### Schritt 2: Export – der ganze Artikel als eine Datei Über /export kommt der komplette Artikel als eine einzige XLIFF-Datei heraus: alle Segmente paarweise, deutsche Quelle neben dem zielsprachlichen Feld. Eine Datei, ein Zustand, ein Wahrheitspunkt – statt 1.700 Formularfeldern, von denen der Server nur die ersten 1.000 annimmt. ### Kurz erklärt: Was ist eine XLIFF-Datei? XLIFF steht für „XML Localization Interchange File Format“ – ein seit Jahren etablierter Industriestandard für Übersetzungen. Man kann es sich als genormten Container vorstellen: Eine XLIFF-Datei enthält den Text sauber in Segmente zerlegt, und zu jedem Segment gehört ein Quellfeld (das Original) und ein Zielfeld (die Übersetzung). Formatierung, Tags und Reihenfolge bleiben dabei erhalten. Der Charme daran: Fast jedes ernstzunehmende Übersetzungswerkzeug spricht XLIFF – auch WPML exportiert und importiert in diesem Format. Statt Text durch enge Formularfelder zu quetschen, reicht man eine einzige, prüfbare Datei herum. Genau das nutzen wir: WPML gibt den Artikel als XLIFF heraus, die KI füllt die Zielfelder, und WPML liest die fertige Datei wieder ein – ohne dass unterwegs etwas verloren geht. ### Schritt 3: Sortieren – nicht alles gehört übersetzt Ein Skript teilt die Segmente in drei Stapel: **übersetzen**, **nicht anfassen** (Markennamen, URLs, ACF-Settings – alles, was in jeder Sprache identisch bleiben muss) und **schon fertig** (die 462 TM-Treffer). Dieser Schritt wirkt unscheinbar, verhindert aber die zwei klassischen Fehler maschineller Übersetzung: dass jemand eine URL „übersetzt“ oder ein technisches Einstellungsfeld in schönem Zielsprachen-Prosa endet. ### Schritt 4: Parallele KI-Agenten – 14 Batches, ein Glossar Die verbleibenden Segmente gehen in 14 Batches à etwa 85 Segmente an parallele KI-Agenten. Damit vierzehn Übersetzer nicht vierzehn Vokabeln für denselben Fachbegriff wählen, arbeiten alle mit einem gemeinsamen Terminologie-Glossar, das vorher aus den vorhandenen Übersetzungen gebaut wurde. Konsistenz entsteht hier nicht durch Hoffnung, sondern durch eine geteilte Wortliste. Die Parallelität ist der Grund, warum aus einem 10.000-Wörter-Artikel keine Wochenaufgabe wird: 14 Arbeiter, gleichzeitig, mit identischen Regeln. ![Pipeline-Log: 14 Batches, Prüfungen und Import-Bestätigung der KI-Übersetzung](https://4eck-media.de/wp-content/uploads/2026/07/bild-06-pipeline-log.avif) ### Schritt 5: Prüfungen vor dem Import – die Maschine kontrolliert die Maschine Bevor irgendetwas zurück in WordPress fließt, läuft jede übersetzte Datei durch automatische Prüfungen: Ist das XML valide? Sind alle HTML-Tags vollständig? Haben Listen gleich viele Punkte wie im Original? Sind Links unangetastet? Und: Stehen noch deutsche Restwörter im Zieltext? Für die letzte Prüfung gibt es eine Whitelist mit Eigennamen – eine „Deutsche Gesellschaft für …“ heißt in jeder Sprache so und darf nicht als Übersetzungsfehler durchfallen. Fällt ein Batch durch, wird er korrigiert, bevor er weiterdarf. Nichts erreicht den Import ungeprüft. ### Schritt 6: Import – eine Operation, am Formular vorbei Die geprüfte XLIFF-Datei geht über /import zurück – als eine einzige Operation, direkt über WPMLs interne Funktionen. Kein Browser-Formular, kein max_input_vars-Limit, kein stilles Verwerfen von Feldern. Genau die Stelle, an der der alte Weg brach, existiert in diesem Weg schlicht nicht. ### Schritt 7: Kontroll-Export – Vertrauen ist gut, Abgleich ist Pflicht Zum Schluss leiten wir denselben Artikel noch einmal aus und gleichen ab: Steht in jedem Zielfeld wirklich das, was importiert wurde? Diese Paranoia haben wir uns bei den leeren Feldern mit dem Häkchen „Translation is complete“ antrainiert. Einem Status-Häkchen glauben wir seitdem nicht mehr – einem Export-Abgleich schon. [Screenshot-Platzhalter: Artikelseite vorher/nachher – leere Übersetzung mit „complete“-Häkchen vs. vollständig übersetzte Live-Seite] ### Was heißt das in Zahlen? 1.215 Segmente frisch übersetzt, geprüft und importiert – in 3 bis 5 Minuten. Zum Vergleich die alte Rechnung für denselben Artikel: eine Woche Übersetzerarbeit, plus eine weitere Woche, um herauszusuchen, was der Editor beim Speichern verloren hat. Und der Workflow skaliert: Für Englisch haben wir an einem Tag 638 Segmente über 50 Referenzen, einen Blogartikel und 4 Seiten geschafft; Französisch steht bei 53 Referenzen komplett mit 401 übersetzten und korrigierten Segmenten. Heute sind EN, FR und PL zu 100 % complete – Blog, Referenzen, Seiten. Spanisch läuft gerade autonom, nach einer schriftlichen Arbeitsanweisung. Der Mensch in der Kette ist nicht verschwunden. Er ist nur vom Abtippen zum Abnehmen gewechselt. Der Workflow am Beispiel unseres größten Artikels - 1.725 Segmente, über 10.000 Wörter – der größte Artikel der Website - Translation Memory lieferte 462 Segmente fertig vor - 14 parallele KI-Agenten, Batches à ~85 Segmente, gemeinsames Terminologie-Glossar - 5 automatische Prüfungen vor dem Import: XML, HTML-Tags, Listenpunkte, Links, deutsche Restwörter - Ergebnis: 1.215 Segmente übersetzt, geprüft und importiert in 3 bis 5 Minuten - Alter Weg: eine Woche übersetzen plus eine Woche suchen, was nicht gespeichert wurde ### Häufige Fragen zum Workflow Warum wird der Artikel als eine einzige XLIFF-Datei exportiert? Weil eine Datei ein konsistenter Zustand ist: Quelle und Ziel liegen paarweise nebeneinander, nichts wird vom Server abgeschnitten, und der Import läuft später als eine Operation zurück. Genau das kann das Browser-Formular bei großen Artikeln nicht leisten – dort brach der Prozess ab. Wie stellen Sie sicher, dass 14 parallele Agenten einheitlich übersetzen? Über ein gemeinsames Terminologie-Glossar, das vor dem Lauf aus den vorhandenen Übersetzungen gebaut wird. Jeder Batch arbeitet mit derselben Wortliste; Fachbegriffe und wiederkehrende Formulierungen bleiben dadurch über alle Batches konsistent. Was passiert, wenn eine Übersetzung die automatischen Prüfungen nicht besteht? Dann erreicht sie den Import nicht. Die Prüfungen laufen vor dem Einspielen: XML-Validität, vollständige HTML-Tags, gleiche Listenpunkt-Anzahl, unangetastete Links, keine deutschen Restwörter. Erst eine saubere Datei geht über /import zurück. Woher wissen Sie, dass nach dem Import wirklich alles angekommen ist? Durch den Kontroll-Export: Der Artikel wird nach dem Import erneut ausgeleitet und gegen die eingespielte Fassung abgeglichen. Dem Status-Häkchen allein vertrauen wir nicht mehr – leere Felder mit „Translation is complete“ waren schließlich der Ausgangspunkt dieser ganzen Geschichte. ### Der eigentliche Hebel fürs Tempo: parallel statt nacheinander Dass aus einer Wochenaufgabe ein paar Minuten werden, liegt nicht an schnellerem Tippen. Es liegt an Parallelität. Statt Feld für Feld und Sprache nach Sprache abzuarbeiten, zerlegt Claude die Arbeit in unabhängige Batches, übersetzt sie gleichzeitig und führt am Ende alles zusammen – inklusive der Prüfungen. ![Schema der parallelen Orchestrierung: Claude teilt die Arbeit in Batches, führt sie gleichzeitig aus und führt sie zusammen; Zeitvergleich Wochen gegenüber Minuten](https://4eck-media.de/wp-content/uploads/2026/07/bild-09-parallel-orchestrierung.avif) Das Angenehme daran: Claude macht das oft von selbst. Es erkennt, dass die einzelnen Batches nichts voneinander wissen müssen, und startet sie parallel, ohne dass man extra darum bitten muss. Aber eben nicht immer. Bei einer vage formulierten Anweisung arbeitet das Modell auch mal brav der Reihe nach – das Ergebnis stimmt, nur dauert es länger. Deshalb schreiben wir das Tempo direkt in den Prompt. Ein Satz reicht, und man hängt ihn einfach an die Arbeitsanweisung an: ``` Arbeite die Batches parallel ab, nicht nacheinander: Starte mehrere Übersetzungs-Agenten gleichzeitig und führe die Ergebnisse am Ende zusammen. Process the batches in parallel, not one after another: run several translation agents at the same time and merge the results at the end. ``` Der Effekt ist genau der aus der Grafik: Wochen werden zu Minuten. Und in einem Geschäft, in dem Zeit der einzige Rohstoff ist, den man nicht kaufen kann, entscheidet am Ende oft nicht das bessere Produkt, sondern das schnellere. Wer eine Idee sofort umsetzt, ist da, bevor der Wettbewerb überhaupt anfängt. ## Woher wir wissen, dass wirklich ALLES übersetzt ist Kurze Antwort: Wir glauben keinem einzigen Häkchen. Stattdessen prüfen wir jede Sprache dreistufig – erst den Gesamtstatus, dann jedes einzelne Segment, dann den Inhalt selbst. Erst wenn alle drei Stufen sauber sind, gilt eine Sprache bei uns als fertig. Und genau diese Skepsis hat uns Fehler finden lassen, die im deutschen Original seit Jahren niemandem aufgefallen waren. Wenn Sie bis hierhin gelesen haben, kennen Sie den Grund für unser Misstrauen: 1.247 Segmente mit gesetztem Häkchen „Translation is complete“ – und dahinter leere Felder. Wer das einmal erlebt hat, baut sich ein Kontrollsystem. Unseres hat drei Stufen. ### Stufe 1: Wo stehen wir überhaupt? Die Status-Matrix. Pro Sprache und Inhaltstyp – Blogartikel, Referenzen, Seiten – sehen wir auf einen Blick: complete, veraltet oder unübersetzt. Das ist der Ein-Minuten-Überblick, den man als Projektmanager jeden Morgen haben will. Keine zwanzig Klicks durchs WPML-Backend, sondern eine Tabelle, die die Frage beantwortet: Wo fehlt noch etwas? Die Matrix sagt allerdings nur, was WPML *glaubt*. Deshalb gibt es Stufe 2. ![Status-Matrix vorher/nachher: Übersetzungslücken zu Projektbeginn und vollständig grüne Sprachen EN, FR, PL](https://4eck-media.de/wp-content/uploads/2026/07/bild-08-status-matrix.avif) ### Stufe 2: Stimmen die Häkchen? Der Segment-Scan. Wir exportieren jeden einzelnen Übersetzungsjob und suchen maschinell nach zwei Dingen: leeren Zielfeldern und deutschem Text, wo keiner sein dürfte. Den Status-Häkchen darf man nämlich nicht glauben – genau mit diesem Scan haben wir die Artikel gefunden, bei denen „complete“ auf leeren Feldern stand. Der Status war gepflegt, die Live-Seite halb deutsch. Das klingt nach viel Arbeit, ist aber ein Skript: exportieren, abgleichen, Befundliste. Eigennamen wie „Deutsche Gesellschaft für…“ stehen auf einer Whitelist, damit sie nicht als Fehler durchrutschen. ### Stufe 3: Ist es auch gutes Polnisch? Ein leeres Feld findet jedes Skript. Aber einen Germanismus? Einen nicht deklinierten Eigennamen? Dafür lassen wir KI-Agenten die Übersetzung als muttersprachliche Lektoren gegen das deutsche Original lesen – Satz für Satz, Sinn gegen Sinn. Das Ergebnis beim Polnischen hat uns selbst überrascht. Alle 53 Referenzen standen auf „complete“. Das Lektorat fand trotzdem rund 70 Befunde: Germanismen, nicht deklinierte Eigennamen – und in einem Fall die Beschreibung des falschen Kunden. Ein Copy-Paste-Fehler, der sogar im deutschen Original steckte. Jahrelang online, von keinem Menschen bemerkt, von der KI beim systematischen Abgleich gefunden. Alle 132 Korrekturen haben wir an einem Abend eingespielt. Das ist für uns der eigentliche Punkt dieses Kapitels: Die KI übersetzt nicht nur – sie ist der Auditor, der beim 1.500sten Segment nicht müde wird. Ein menschlicher Lektor liest 53 Referenzseiten und ermüdet irgendwann; das ist keine Kritik, das ist Biologie. Der Agent liest Segment 1.500 mit derselben Aufmerksamkeit wie Segment 1. Die dreistufige Qualitätskontrolle - Stufe 1 – Status-Matrix: Sprache × Inhaltstyp, Gesamtbild in einer Minute - Stufe 2 – Segment-Scan: jeden Job exportieren, leere Felder und deutsche Restwörter suchen; Häkchen zählen nicht - Stufe 3 – muttersprachliches KI-Lektorat gegen das Original: Sinnfehler, Kalke, Deklinationen - Praxisbeleg: 53 polnische Referenzen „complete“ – trotzdem ~70 Befunde, darunter der falsche Kunde in einer Beschreibung - Alle 132 Korrekturen an einem Abend eingespielt ### Häufige Fragen zur Qualitätskontrolle Reicht die Status-Anzeige in WPML nicht aus? Nein. Der Status sagt nur, dass ein Übersetzungsjob abgeschlossen wurde – nicht, dass der Inhalt auf der Live-Seite angekommen ist. Wir hatten 1.247 Segmente mit Häkchen und leeren Feldern. Deshalb prüfen wir immer auf Segment-Ebene nach. Wer kontrolliert die Kontrolle – kann die KI ihre eigenen Fehler finden? Das Lektorat prüft gegen das deutsche Original, nicht gegen die eigene Übersetzung, und läuft als getrennter Schritt mit getrennter Rolle. Dazu kommen automatische Checks vor jedem Import: valides XML, vollständige HTML-Tags, unangetastete Links. Am Ende nimmt bei uns trotzdem ein Mensch Stichproben ab. Wie lange dauert so ein Prüfdurchlauf? Die Status-Matrix ist eine Minute. Segment-Scan und Lektorat laufen automatisiert – beim Polnischen haben wir alle 132 Korrekturen aus dem Lektorat an einem einzigen Abend eingespielt. Findet das Lektorat wirklich Dinge, die Menschen übersehen? Ja, nachweislich: Der Copy-Paste-Fehler mit dem falschen Kunden stand sogar im deutschen Original – und war dort nie jemandem aufgefallen. Der systematische Abgleich Satz für Satz ermüdet nicht, und genau darin liegt sein Vorteil. ## Wer übersetzt und wer kontrolliert: die Arbeitsteilung der Modelle Der Geheimtipp aus unserem Workflow ist keine Software, sondern eine Personalentscheidung: Wir setzen zwei verschiedene KI-Modelle ein – eines übersetzt, das andere kontrolliert. Diese Rollenteilung ist der Grund, warum die Rechnung am Ende aufgeht. Die Aufteilung sieht so aus: Claude Opus 4.8 ist das ausführende Modell. Es ist schnell und bei Massenarbeit deutlich günstiger – ideal für die eigentliche Übersetzungsarbeit, die parallelen Batches à rund 85 Segmente, das Abarbeiten der Warteschlange. Claude Fable 5 ist analytisch stärker, aber teurer – und wird deshalb nur punktuell gebraucht: Es plant den Ablauf, prüft Stichproben und nimmt das Ergebnis ab. Wenn Ihnen das bekannt vorkommt, liegt das daran, dass Sie so vermutlich Ihr Team organisieren: Der Junior übersetzt, der Senior reviewt. Niemand lässt den teuersten Kopf im Haus 1.700 Segmente Fließtext übertragen – er soll die Struktur festlegen und am Ende draufschauen. Genau das machen wir mit den Modellen. Nur dass beide nachts arbeiten und nicht krank werden. ### Schnell, günstig, gut – wähle zwei? Das alte Projektmanagement-Dreieck sagt: Von schnell, günstig und gut bekommen Sie immer nur zwei. Die Rollenteilung ist unsere Antwort darauf – sie liefert alle drei. Schnell, weil das ausführende Modell parallel in Batches arbeitet. Günstig, weil das teure Modell nur für die Momente bezahlt wird, in denen Analyse wirklich gebraucht wird: Planung, Stichprobe, Abnahme. Und gut, weil eben nicht dasselbe Modell seine eigene Arbeit durchwinkt, sondern eine zweite, stärkere Instanz kontrolliert. Wichtig ist die Reihenfolge: Erst plant das Senior-Modell den Auftrag – was wird übersetzt, was bleibt unangetastet (Marken, URLs, ACF-Settings), welches Terminologie-Glossar gilt. Das Glossar bauen wir aus den vorhandenen Übersetzungen, damit alle parallelen Agenten dieselben Begriffe verwenden – sonst heißt derselbe Fachbegriff in Batch 3 anders als in Batch 11. Dann arbeitet das Junior-Modell die Masse ab. Am Ende kommt der Senior zurück und prüft per Stichprobe, ob das Ergebnis der Vorgabe entspricht. Kein Segment geht in den Import, das nicht durch diese Kette gelaufen ist. Beim 1.725-Segment-Artikel sah das konkret so aus: 14 parallele Agenten, jeder mit einem Batch von rund 85 Segmenten und demselben Glossar. Die Masse lief auf dem günstigen Modell – die Planung davor und die Abnahme danach auf dem starken. Ergebnis in 3 bis 5 Minuten, ohne dass die teure Instanz auch nur ein Fließtext-Segment selbst übersetzt hätte. Für Sie als Projektmanager heißt das: Denken Sie bei KI-Projekten nicht in der Frage „Welches Modell ist das beste?“, sondern „Welche Rolle braucht welches Modell?“. Das beste Modell überall einzusetzen ist so sinnvoll, wie jede Aufgabe im Team an die teuerste Person zu geben. Wer übersetzt, wer kontrolliert - Claude Opus 4.8 übersetzt: schnell, günstiger bei Massenarbeit, parallele Batches à ~85 Segmente - Claude Fable 5 plant, prüft Stichproben, nimmt ab: analytisch stärker, wird nur punktuell gebraucht - Prinzip: Junior übersetzt, Senior reviewt – beide arbeiten nachts und werden nicht krank - Ergebnis: schnell UND günstig UND gut – die Rollenteilung hebelt das alte „wähle zwei“ aus ## Was das in Zahlen bedeutet Die Bilanz zuerst: 116 Blogartikel, 53 Referenzen, 19 Seiten – Englisch, Französisch und Polnisch stehen zu 100 Prozent auf complete. Spanisch läuft gerade, und zwar autonom: nach einer schriftlichen Arbeitsanweisung, ohne dass jemand danebensitzt. Der Zeitrahmen dafür: Stunden statt Wochen. Zwei Beispiele, die den Unterschied greifbar machen. Für Englisch haben wir 638 Segmente an einem einzigen Tag übersetzt, geprüft und importiert – 50 Referenzen, ein Blogartikel, vier Seiten. Und der größte Brocken der ganzen Website, der GEO-Framework-Artikel mit 1.725 Segmenten und über 10.000 Wörtern, war in 3 bis 5 Minuten durch: 462 Segmente lieferte das Translation Memory fertig vor, die restlichen 1.215 haben 14 parallele KI-Agenten übersetzt, geprüft und importiert. Derselbe Artikel, an dem der Übersetzungseditor vorher mit 1.247 festhängenden Segmenten gescheitert war. Dazu Französisch: 53 Referenzen komplett, 401 Segmente übersetzt oder korrigiert. Und beim Polnischen gingen alle 132 Korrekturen aus dem Lektorat an einem Abend live. Bei den Kosten ist die Logik einfach: Wir zahlen ein Claude-Abo – keine Abrechnung pro Wort und pro Sprache. WPMLs automatische Übersetzung über Credits (DeepL, Google, Microsoft) existiert, wird aber genau so abgerechnet: pro Wort, pro Sprache. Bei 116 Artikeln mal mehrere Sprachen summiert sich das erheblich. Dazu kommt: Das Abo deckt nicht nur die Übersetzung ab, sondern auch das Lektorat, die Prüfskripte und den Kontroll-Export – Arbeitsschritte, die in einer Pro-Wort-Kalkulation gar nicht erst vorkommen. Dazu kommt ein Effekt, den wir nicht eingeplant hatten: Anfragen kommen inzwischen aus der Schweiz, Österreich, Japan, Kanada und den USA. KI-Assistenten empfehlen uns auf Anfragen wie „beste WordPress-Agentur“ sowie zu SEO, Marketing und KI-Integration. Der Markt ist global geworden – und eine Website, die nur Deutsch spricht, ist auf diesem Markt unsichtbar. ### Was KI hier nicht kann Damit kein falscher Eindruck entsteht: Wir behaupten nicht, dass KI alles kann. Juristische Texte und Marken-Slogans brauchen am Ende der Kette einen Menschen – beim einen hängt Haftung dran, beim anderen Nuance, und beides delegiert man nicht an ein Sprachmodell. Auch in unserem Workflow nimmt eine Person die finale Stichprobe ab. Aber das ist kein Argument gegen den Ansatz, sondern seine Begrenzung. Wo sich Wochen an Routinearbeit automatisieren lassen – 1.725 Segmente exportieren, übersetzen, prüfen, importieren -, ist es die einzige rationale Entscheidung, das zu tun. Die Verantwortung trägt dabei der Prozess mit seinen Prüfungen: Status-Matrix, Segment-Scan, Lektorat, automatische Checks vor jedem Import. Nicht der Glaube ans Modell. Das Projekt in Zahlen - 116 Blogartikel, 53 Referenzen, 19 Seiten – EN, FR und PL zu 100% complete - Spanisch läuft autonom nach schriftlicher Arbeitsanweisung - 638 EN-Segmente an einem Tag; der 1.725-Segment-Artikel in 3 bis 5 Minuten - Kosten: ein Claude-Abo statt Abrechnung pro Wort und Sprache - Grenze: Jura-Texte und Marken-Slogans brauchen am Ende einen Menschen ## Was Sie brauchen, um das nachzubauen Die gute Nachricht vorweg: Die Einkaufsliste ist kurz. Sie brauchen keine neue Übersetzungsplattform, keine Migration und kein Sonderbudget – sondern vier Dinge, von denen Sie drei vermutlich schon haben. **Erstens: WordPress mit WPML.** Jede Version mit XLIFF-Support genügt. Der ganze Workflow nutzt Funktionen, die in WPML bereits stecken – XLIFF-Export und -Import, Translation Memory, die internen APIs. Es wird nichts ersetzt, nur zugänglich gemacht. **Zweitens: ein Entwickler für einen halben Tag.** Das mu-plugin – rund 300 bis 400 Zeilen PHP, reine Wrapper um WPML-interne Funktionen – generiert die KI in etwa zehn Minuten. Der Mensch macht das, was man nicht delegiert: Code-Review, Deployment, IP-Allowlist. Bei uns war das ein Abend. Zur Sicherheit: Nur die festen Ausgangs-IPs der KI-Umgebung kommen durch, keine Tokens im Code, und löschen kann das Plugin nichts – es exportiert, importiert und meldet Status, mehr nicht. **Drittens: ein Claude-Abo** mit Zugang zu Claude Code und Cowork. Das ist der Motor des Ganzen – und der Grund, warum keine Pro-Wort-Rechnung entsteht. **Viertens: eine Person für die finale Abnahme.** Muttersprachliche Stichproben am Ende der Kette. Die KI lektoriert systematisch, aber die letzte Freigabe bleibt bei einem Menschen. Das muss kein Übersetzer in Vollzeit sein – es geht um Stichproben, nicht um Komplettlektüre; das Komplette hat die Maschine davor schon erledigt. ### Wann lohnt sich unser Weg nicht? Auch das gehört in eine ehrliche Checkliste. Eine 5-Seiten-Website übersetzen Sie schneller von Hand – der Aufbau des Workflows lohnt sich erst, wenn die Menge das Manuelle schlägt. Und juristische Inhalte gehen bei uns grundsätzlich nur mit professionellem Review; das automatisieren wir bewusst nicht. Für alles dazwischen – Blogs, Referenzen, Kompetenz-Seiten in mehreren Sprachen – gilt: Die Werkzeuge liegen bereit. XLIFF-Export, Translation Memory, die internen APIs – das alles steckt schon in WPML; die vier Routen des Plugins (/status, /requeue, /export, /import) machen es nur von außen erreichbar. Was fehlt, ist meist nicht Technik, sondern die Entscheidung, sie zusammenzustecken. Was Sie zum Nachbau brauchen - WordPress + WPML, jede Version mit XLIFF-Support - Ein Entwickler für einen halben Tag: Plugin-Review, Deployment, IP-Allowlist - Claude-Abo mit Code + Cowork - Eine Person für die muttersprachliche Stichproben-Abnahme - Nicht sinnvoll bei: 5-Seiten-Websites (Handarbeit ist schneller) und Jura-Inhalten ohne professionelles Review ## Zum Mitnehmen: Prompt 1 – die Nachrüstung (für Claude Code oder Ihren Entwickler) Das Versprechen aus der Einleitung lösen wir jetzt ein. Der folgende Prompt ist die komprimierte Fassung der Spezifikation, mit der unser Helfer-Plugin entstanden ist. Kopieren Sie ihn in Claude Code – das Ergebnis ist ein Plugin-Entwurf, den Ihr Entwickler reviewt und deployed. Genau so ist unseres entstanden: zehn Minuten Generierung, ein Abend Review und Deployment. Zwei Dinge müssen Sie zusätzlich von Hand erledigen, ohne die nichts funktioniert: Erstens: Schalten Sie Ihre Website-Domain für die KI-Umgebung frei. Wichtig – das passiert nicht in der Claude-App, sondern in den Kontoeinstellungen auf der Website claude.ai, unter Capabilities → Allow network egress → Additional allowed domains. Dort tragen Sie Ihre Domain ein (bei uns 4eck-media.de). Der Grund: Claude arbeitet in einer abgeschotteten Umgebung, die von sich aus nicht ins offene Netz darf. Fehlt dieser Eintrag, blockiert die Umgebung jede Anfrage an Ihren Server – requeue, Export und Import scheitern, bevor sie überhaupt starten. Ein einmaliger Handgriff, ohne den der ganze Workflow nicht läuft. ![Einstellungen auf claude.ai: eigene Website-Domain unter Capabilities, Allow network egress, Additional allowed domains eingetragen](https://4eck-media.de/wp-content/uploads/2026/07/bild-11-claude-domain-allowlist.avif) Zweitens: Wenn Sie Claude auch im Browser nutzen (etwa für Kontrollen im WordPress-Admin), fügen Sie Ihre Website in der Claude-Browser-Erweiterung zur Liste der erlaubten Seiten hinzu. ``` Task: Build a WordPress mu-plugin ("translation-helper", single PHP file, ~300–400 lines) that exposes existing WPML translation operations over HTTP, so an external AI agent can run a full translation cycle without using the wp-admin browser forms. Routes (REST namespace translation-helper/v1): 1. GET /ping → { ok, wpml_version, plugin_version } - health check, no params. 2. GET /status → params: lang (required), type (post type, e.g. post/page/custom), per_page, page. Returns items with: post_id, title, target_lang, translation_status (not_translated | in_progress | needs_update | complete), job_id, needs_requeue. 3. POST /requeue → JSON body { post_id, target_lang }. Re-queues the post for translation using WPML's Translation Management API (equivalent to sending it to translation in the dashboard). WPML must prefill targets from Translation Memory. Returns new job_id. 4. GET /export → param job_id. Streams the job as XLIFF 1.2 (XML). 5. POST /import → multipart: job_id + file (the translated XLIFF). Applies the translation using WPML's own import routines. Returns { ok, segments_total, segments_applied, status }. Hard requirements: - Wrap EXISTING WPML functions only (Translation Management API, XLIFF export/import). Do not reimplement translation logic. Confirm exact function names against the installed WPML version before finalizing. - Auth: IP allowlist from a constant in the plugin file. Behind Cloudflare/proxies check CF-Connecting-IP (or X-Forwarded-For), not REMOTE_ADDR. Reject everything else with 403. - The plugin must not be able to delete content, create posts, or modify anything except applying translation jobs via /import. - Rate limiting: one concurrent write (requeue/import); return { code: "busy" } or { code: "rate_limit" } so the client can back off and retry. - Log every write operation (timestamp, IP, route, post_id/job_id) to a rotating file. Deliverables: the plugin file + a short README with the curl calls for all five routes. ``` Prompt 1: die Nachrüstung in Kürze - Ein mu-plugin, ~300–400 Zeilen, fünf Routen: ping, status, requeue, export, import - Nur Wrapper um vorhandene WPML-Funktionen – übersetzt selbst nichts, löscht nichts - Zugriff per IP-Allowlist, jede Schreiboperation wird geloggt - Generierung: ~10 Minuten. Review und Deployment durch einen Menschen: ein Abend - Danach läuft der komplette Übersetzungszyklus ohne Browser-Formular ## Zum Mitnehmen: Prompt 2 – die Arbeitsanweisung für die Übersetzung (Claude Cowork) Der zweite Prompt ist die Arbeitsanweisung für die eigentliche Übersetzung. Er setzt voraus, dass das Plugin aus Prompt 1 läuft. Wir nutzen ihn in Claude Cowork; dort kann die KI Dateien verarbeiten, Skripte ausführen und stundenlang autonom arbeiten. Passen Sie Sprache, Domain und die „Nicht übersetzen“-Liste an Ihr Projekt an. ``` Task: Translate the website content of [YOUR-DOMAIN] from [SOURCE-LANG] to [TARGET-LANG] using the translation-helper plugin (REST namespace translation-helper/v1). Work autonomously, sequentially, and keep a verifiable journal. Cycle per post: 1. POST /requeue { post_id, target_lang } → new job_id. WPML prefills targets from Translation Memory - do not re-translate those segments. 2. GET /export?job_id=... → save the XLIFF (keep it as "before" artifact). 3. Classify every trans-unit: (a) TRANSLATE if target is empty or identical to a source that is real [SOURCE-LANG] text; (b) KEEP AS IS if it is a brand name, person, city, URL, or a short technical setting value; (c) TM-DONE if target differs from source - never overwrite these, but reuse them as your terminology reference. 4. Translate with strict rules: reproduce the HTML structure of the source byte-for-byte (same tags, attributes, entities, number of
  • ); translate only human text; SEO title ≤ 60 chars, meta description ≤ 160; [add your language conventions here]. Do not translate: [YOUR BRAND LIST], people, places, technical terms (SEO, PageSpeed…). 5. Validate before import: XML parses; tag list of every changed target equals its source; list item counts match; no leftover [SOURCE-LANG] function words (keep a whitelist for proper names). 6. POST /import (multipart) → expect segments_applied == segments_total, status complete. 7. GET /export again → verify your translations are actually in the re-export ("after" artifact). A status flag alone is NOT proof. 8. Journal line per post: post_id, job_id, segments total/prefilled/translated/kept, import result, verified yes/no. Constraints: all write requests strictly sequential; on "busy"/"rate_limit" back off 30→60→120s; batches of 5–10 posts; never touch posts outside the given list; never change source content; skip WordPress sample pages. Order of work: pilot on ONE small post first and show me the result. Then: references → pages → blog posts → [other post types]. Report after every batch. ``` Und der Tipp, der bei uns den größten Unterschied bei den Kosten gemacht hat: Trennen Sie die Rollen. Die Massenübersetzung fährt bei uns Claude Opus 4.8 – schnell und günstig. Die Planung, Stichproben und Abnahme macht Claude Fable 5 – analytisch stärker, wird aber nur punktuell gebraucht. Junior übersetzt, Senior reviewt. So bekommen Sie Qualität, Geschwindigkeit und einen vernünftigen Preis gleichzeitig. ### Häufige Fragen zur WordPress-Übersetzung mit KI Ersetzt das einen professionellen Übersetzer? Nein – und das sagen wir bewusst so deutlich. Für Jura-Texte und Marken-Slogans gehört ein Mensch ans Ende der Kette, daran ändert auch die beste KI nichts. Was die KI ersetzt, ist die Massenarbeit: 116 Blogartikel, 53 Referenzen und 199 Kompetenz-Seiten von Hand übersetzen zu lassen, war für uns nie eine realistische Option. Mit einem sauberen Prüfprozess – automatische Checks vor dem Import plus muttersprachliches Lektorat gegen das Original – ist KI für diesen Massen-Content die einzige rationale Entscheidung. Was kostet die Übersetzung einer WordPress-Website mit KI? Ehrlich gesagt: deutlich weniger als die Alternativen, aber die genaue Zahl hängt von Ihrem Setup ab. Der entscheidende Unterschied liegt im Abrechnungsmodell – die automatische Übersetzung via WPML-Credits (DeepL, Google, Microsoft) wird pro Wort und pro Sprache abgerechnet, was bei 116 Artikeln mal mehrere Sprachen sehr teuer wird. Unser Workflow läuft dagegen über ein KI-Abo, das nicht pro Wort tickt. Dazu kommt einmalig die Einrichtung: rund 300–400 Zeilen PHP, vom Entwickler an einem Abend deployed. Funktioniert das auch mit Polylang oder TranslatePress? Im Prinzip ja, denn die Kernidee ist plugin-unabhängig: Inhalte per Export aus dem System holen, extern übersetzen und prüfen, dann per Import zurückspielen – am Browser-Formular vorbei. Genau dieses Formular war bei uns das Nadelöhr (max_input_vars schnitt bei 1.725 Segmenten still 1.247 ab). Die konkreten Routen unseres geo-helper-Plugins sind allerdings Wrapper um WPML-interne Funktionen; für Polylang oder TranslatePress müsste ein Entwickler die Anbindung an deren Schnittstellen neu bauen. Das Muster bleibt dasselbe, die Implementierung nicht. Was ist mit SEO und Hreflang? WPML setzt die hreflang-Auszeichnung selbst, sobald eine Übersetzung als vollständig gilt – darum müssen Sie sich nicht extra kümmern. Yoast-Titel und Metadescriptions laufen als ganz normale Segmente durch den XLIFF-Export mit und werden im selben Zyklus übersetzt. Wichtig ist nur, dass die KI-Agenten dabei die Längenlimits für Titel und Description respektieren, sonst schneidet Google ab. Das lässt sich als Regel in die Arbeitsanweisung schreiben und automatisch prüfen. Ist es sicher, einer KI Zugriff auf die Website zu geben? Ja, weil die KI gar keinen allgemeinen Zugriff bekommt. Das mu-plugin öffnet nur vier eng begrenzte Routen für Übersetzungsoperationen – Status, Requeue, Export, Import – und erfindet nichts Neues, sondern wrappt existierende WPML-Funktionen. Eine IP-Allowlist lässt nur die festen Ausgangs-IPs der KI-Umgebung durch, Tokens liegen nicht im Code. Und konstruktionsbedingt kann das Plugin keine Inhalte löschen und keine neuen erzeugen: Der schlimmste denkbare Fall ist eine schlechte Übersetzung, die im Review hängen bleibt. Was passiert bei einem WPML-Update? In der Regel: nichts, denn das Plugin nutzt die offiziellen internen Funktionen von WPML statt eigener Datenbank-Tricks. Genau diese Funktionen treiben auch den regulären XLIFF-Export und das Translation Memory an – sie sind das stabile Fundament, kaputt war bei uns nur die Browser-Formular-Ebene. Trotzdem empfehlen wir nach jedem Major-Update einen Pilot-Zyklus: einen Artikel durch requeue, export, import und Kontroll-Export schicken und das Ergebnis abgleichen. Kostet Minuten und nimmt dem Update den Schrecken. Wie viele Sprachen sind realistisch? Unsere ehrliche Zahl: 10 Sprachen sind in WPML angelegt, 4 davon sind komplett – EN, FR und PL zu 100 Prozent, Spanisch läuft gerade autonom nach schriftlicher Arbeitsanweisung. Der Engpass ist dabei nicht mehr die Übersetzung selbst; 638 englische Segmente an einem Tag oder 1.215 Segmente in 3 bis 5 Minuten zeigen, wie schnell das geht. Der Engpass ist das Review: Wer prüft die Ergebnisse, wer entscheidet bei Terminologie-Fragen? Planen Sie Sprachen deshalb nach Ihrer Review-Kapazität, nicht nach der technischen Machbarkeit. Wie lange dauert die Einrichtung? Kürzer, als die meisten erwarten: Bei uns brauchte der Entwickler einen halben Tag, und der erste Artikel lief noch am selben Tag durch den kompletten Zyklus. Die Spezifikation für das mu-plugin ist fertig und kopierbar – Claude Code generierte den Code in rund 10 Minuten, Review, Deployment und IP-Allowlist erledigte unser Entwickler an einem Abend. Danach ist der Workflow sofort produktiv: requeue, export, übersetzen, prüfen, import, Kontroll-Export. ## Glossar: die Begriffe aus diesem Artikel **ATE (Advanced Translation Editor)** – Der browserbasierte Übersetzungseditor von WPML, in dem Übersetzungen Segment für Segment bearbeitet und als „complete“ markiert werden. Bei sehr großen Artikeln stößt sein Formular an serverseitige Grenzen – bei uns gingen so 1.247 von 1.725 Segmenten still verloren. **Egress-Allowlist** – Eine Sicherheitsliste fester Ausgangs-IP-Adressen, von denen aus die KI-Umgebung ins Netz geht. Nur diese IPs dürfen die Routen des Übersetzungs-Plugins aufrufen; alle anderen Anfragen werden abgewiesen. **hreflang** – Ein HTML-Attribut, das Suchmaschinen mitteilt, in welcher Sprache und für welche Region eine Seitenversion gedacht ist. WPML setzt hreflang für fertige Übersetzungen automatisch, sodass Google die richtige Sprachversion an die richtigen Nutzer ausspielt. **max_input_vars** – Eine PHP-Einstellung, die begrenzt, wie viele Formularfelder ein Server pro Anfrage annimmt (Standard: 1000). Übersteigt ein Übersetzungsformular dieses Limit – unser größter Artikel hatte über 1.700 Felder – wird der Rest ohne Fehlermeldung abgeschnitten. **mu-plugin** – Ein „Must-Use-Plugin“ in WordPress: liegt in einem eigenen Verzeichnis, ist immer aktiv und lässt sich nicht über das Admin-Backend deaktivieren. Unser geo-helper ist ein solches mu-plugin mit rund 300–400 Zeilen PHP. **Segment** – Die kleinste Übersetzungseinheit in WPML, typischerweise ein Absatz, eine Überschrift oder ein einzelnes Feld. Unser größter Artikel besteht aus 1.725 Segmenten bei über 10.000 Wörtern; unsere KI-Agenten arbeiten sie in Batches à rund 85 Segmente ab. **Translation Memory** – Der Übersetzungsspeicher von WPML: einmal übersetzte Segmente werden gemerkt und bei neuen Jobs automatisch vorbefüllt. Bei unserem größten Artikel lieferte es 462 von 1.725 Segmenten fertig vor. **XLIFF** – Ein XML-basiertes Austauschformat für Übersetzungen, das Quell- und Zieltext paarweise pro Segment ablegt. Über XLIFF-Export und -Import wandern bei uns ganze Artikel als eine Datei am Formular vorbei – der Import ist eine einzige Operation ohne max_input_vars-Limit. ## Hinweis in eigener Sache Alles in diesem Artikel Dargestellte beruht auf unseren eigenen Beobachtungen und Schlussfolgerungen aus der Praxis. Es ist keine allgemeingültige Anleitung und kein rechtlicher oder technischer Rat. Was Sie davon selbst umsetzen, tun Sie auf eigenes Risiko. ## Fazit: Das CMS Nummer eins verdient bessere Übersetzungen Anderthalb Jahrzehnte lang galt bei WordPress-Übersetzungen die alte Projektregel: schnell, günstig, gut – wählen Sie zwei. Unser Fazit nach diesem Projekt: Die Regel war eine Eigenschaft des Werkzeugs, nicht der Aufgabe. Seit der Zyklus am kaputten Formular vorbeiläuft und eine KI die Routine übernimmt, übersetzen wir in Stunden statt Wochen, zahlen ein Abo statt Wort-Tarife – und wissen dank dreistufiger Kontrolle zum ersten Mal belegbar, dass wirklich alles übersetzt ist. Wollen Sie das für Ihre eigene Website? Kopieren Sie diesen Artikel – den ganzen Text – und geben Sie ihn Ihrem Claude Code. Es stehen genug Details darin, dass er den Nachbau daraus ableiten kann; die beiden Prompts oben sind der Startpunkt. Und wenn Sie es lieber machen lassen: Genau dafür sind wir da. Wir bauen mehrsprachige WordPress-Websites, die gefunden werden – von Menschen und von KI-Systemen. Mehr dazu auf unserer Seite [Mehrsprachige Website erstellen lassen](https://4eck-media.de/kompetenzen/mehrsprachige-website-erstellen/) – oder [nehmen Sie Kontakt mit uns auf](https://4eck-media.de/kontakt/).