[Gelöst] Übersetzungen werden im Frontend nicht angezeigt
Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
ich habe das Problem, dass meine Übersetzungen zwar im Backend bearbeitet und auch gespeichert werden, aber nicht im Frontend angezeigt werden.
Dieses Problem hatte ich bereits vor langer Zeit. Es wurde aber nie gelöst. Nun benötige ich dringend eine Lösung für das Problem.
Auf dem Screenshot ist ein Ausschnitt aus dem Übersetzungsmanagement zu sehen. Hier habe ich versucht zwei Beiträge zu übersetzen. Die Übersetzung im ATE habe ich abgeschlossen und gespeichert. Beim erneuten Aufruf über den ATE ist die Übersetzung auch vorhanden. Aber wie auf dem Screenshot zu sehen, lädt sich das System offenbar tot.
Den Lösungsweg darin habe ich angewendet, jedoch ohne Erfolg.
Eine Test-Umgebung (1:1 Kopie der Live-Seite) habe ich bereits eingerichtet. Dort funktioniert die Übersetzung nur über die automatische Übersetzung im WPML-Übersetzungsmanagement-Menü. Wenn ich hier im Beitrag versuche den ATE zu starten, lande ich immer in der Übersetzungsschlange.
Die beiden Seiten (LIVE & Kopie) laufen auf dem selben System. Beim Hoster habe ich angefragt, ob es für die Seiten unterschiedliche Konfigurationen gibt. Das ist aber nicht der Fall.
Das debug.log kann über die wp-config.php aktiviert werden, dies kann ich gerne selbst prüfen. Dazu bräuchte ich bitte temporären Zugriff (WP-Admin und FTP) auf Ihre Seite, vorzugsweise zu einer Test/Staging Seite, an der das Problem nach Möglichkeit repliziert wurde.
Die dafür benötigten Felder finden Sie unterhalb des Kommentarbereichs. Die Informationen, die Sie eingeben, sind privat, d.h. nur Sie und ich können sie sehen und haben Zugriff darauf.
WICHTIG
Bitte erstellen Sie eine Sicherungskopie der Site-Dateien und der Datenbank, bevor Sie uns Zugang gewähren.
-Wenn Sie die wp-admin/FTP-Felder nicht sehen, bedeutet dies, dass Ihre Post- und Website-Login-Daten ÖFFENTLICH gemacht werden. Posten Sie Ihre Website-Details NICHT, wenn Sie die erforderlichen wp-admin/FTP-Felder nicht sehen. Wenn Sie das nicht tun, bitten Sie mich, die private Box zu aktivieren. Die private Box sieht wie folgt aus: versteckter Link
ich habe nun Englisch via "Assign to a translator" zur Übersetzung eingesendet. Im ATE war die Übersetzung bereits zu 100% erledigt und der Job wurde erfolgreich abgeschlossen.
Nun habe ich Schwedisch via "Translate automatically" eingesendet und auch dies wurde erfolgreich abgeschlossen.
Auch im Frontend funktioniert alles: versteckter Link versteckter Link
ich habe eben versucht, den selben Artikel ins dänische zu übersetzen.
Zuerst per automatischer Übersetzung, über das Übersetzungsmanagement. Dies funktioniert offenbar nicht. Der Auftrag hat immer noch den Status "in Bearbeitung".
Dann via Assign to a translator. Hier hat die niederländische Übersetzung funktioniert.
Kann es sein, dass irgendeine Einstellung die automatische Übersetzung blockiert?
Hier noch ein Screen aus dem Tab "Aufträge" im Übersetzungsmanagement:
ich habe dann gleich versucht, diesen erfolgreichen Weg der Übersetzung vie "Assign to a translator" auch auf dem Live-System nachzustellen.
Leider war es hier nicht erfolgreich.
Ich bekomme die Meldung: "Die Synchronisierung mit dem erweiterten Editor ist fehlgeschlagen"
Siehe Screenshot anbei.
Zudem waren die Reaktionsseiten im ATE und auf der Seite während der Bearbeitung sehr sehr lang. Hier muss mit Beginn der Übersetzung eine sehr hohe Last auf dem System gelegen haben.
wäre es auch möglich, dass von Seite der WPML-Server etwas geblockt wird?
Als das Problem Ende 2021 das erste Mal auftrat, hatte ich einige tausend automatische Übersetzungsaufträge angestoßen.
Ich habe auch gerade noch einmal eine weiter Übersetzung getestet. Und er ATE unter der URL: versteckter Link braucht für einen knapp 1.100 Wörter umfassenden Text bereits 20 Minuten für die automatische Übersetzung.
Das kann ja so auch nicht richtig sein.
Vielleicht kannst du das auch in diese Richtung noch einmal prüfen.
ich habe eben noch eine Rückmeldung vom Hoster erhalten.
Er konnte in einem separaten PHP-Error-Log einige Fehlermeldungen finden, hier scheinen falsche include-Pfade eingebunden zu sein, den Auszug aus dem Logfile würde ich dir gerne senden. Kannst du dazu wieder eine private Nachricht generieren:
Hier schon mal ein Auszug:
4[27-Mar-2023 12:06:58] WARNING: [pool domain.net] child 24447 said into stderr: "PHP message: PHP Warning: include(/var/www/vhosts/.../.../wp-content/plugins/wpml-string-translation/vendor/composer/../../classes/slug-translation/custom-types/wpml-st-slu
g-translations.php): failed to open stream: No such file or directory in /var/www/vhosts/.../.../wp-content/plugins/sitepress-multilingual-cms/vendor/composer/ClassLoader.php on line 571"
Besonders interessant ist dieser Teil: composer/../../classes/ da hier die Ordnerebenen gewechselt werden.
eine Blockierung unserer Seite kann eher ausgeschlossen werden, es funktioniert schließlich bei allen anderen Kunden. Können Sie bitte versuchen, das Plugin nach einem Backup zu löschen und via FTP erneut hochzuladen?
Per FTP umgehen Sie etwaige PHP Limits, welche das Paket beim Hochladen abbrechen lassen könnte. Es sieht so aus, als ob hier Dateien fehlen.
ich habe nun nach einem Backup die Plugins WPML CMS, String Translation und Media Translation deaktiviert und gelöscht und anschließend per FTP wieder hochgeladen.
Das habe ich für die Testumgebung und das Livesystem gemacht. Aber eine Änderung hat es nicht gebracht.
Auf dem Testsystem funktioniert die Automatische Übersetzung nicht, die Übersetzung über Übersetzer-Job aber schon.
Auf dem Livesystem funktionieren weiterhin beide Möglichkeiten nicht.
Die Meldung: "Die Synchronisierung mit dem erweiterten Editor ist fehlgeschlagen" wird auf dem Livesystem weiterhin angezeigt.
danke für die Infos. Ich würde nun gerne die Seite auf einer anderen Hosting-Umgebung testen. Wenn es hier erneut wie damals funktioniert, liegt es am Hosting, wo unser Debugging begrenzt ist. Wir können dazu die Seite via Duplicator lokal testen oder wir migrieren die Seite auf unseren eigenen Cloudways Server.
Ich dachte zwar zuerst ebenso an einen Fehler in der Authentifizierung, aber da manche Sprachen in meinem Test funktionierten, kann dies ebenso ausgeschlossen werden.
die Variante ist mir soweit egal. Die, die sich für euch am besten testen lässt, würde ich bevorzugen.
Du musst mir nur sagen, was ich dafür vorbereiten muss.
Welche Sprachen haben bei dir im Test funktioniert?
