[Warten auf das Feedback der Benutzer] Ist die ATE / WPML API immernoch down?
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.
Hintergrund des Themas:
Hallo. Wir haben seit gestern massive Probleme mit dem auto translate everything feature.
Wir können kaum arbeiten.
Gestern war die Endpunkt überlastet / nicht erreichbar.
Aktueller Fehler ist neu:
AMS Server Communication
Active record statement invalid: Mysql2::Error: The MySQL server is running with the --read-only option so it cannot execute this statement
Zudem:
ATE Server Communication
Internal Server Error
{"url":"versteckter Link","requestArgs":{"method":"POST","body":{"jobs":....}
Und ein auto translate Fehler bzgl. %1$s-Platzhaltern in einem string sorgt für einen fatalen Fehler auf einer wichtigen Produktseite.
Wir können ihn nicht mit dem WPML UI lösen, außer manuell hart codiert an der Stelle im Code, an der er abgerufen wird, einen try catch block zu nutzen.
Das ist nicht gut.
Die Symptome:
AMS Server Communication Fehler, ATE Server Communication Internal Server Error, auto translate Fehler mit %1$s-Platzhaltern.
Wir können einen string aus der string translation nicht einmal manuell einem Übersetzer zuweisen.
Wir sind komplett blockiert.
Fragen:
Ist die ATE / WPML API immer noch down?
Wie ist der aktuelle Fortschritt bei der Fehlerbehebung?
Welche Alternativen haben wir, um trotzdem noch arbeiten zu können?
In dem Fall ist wahrscheinlich bereits eine Übersetzung durchgeführt worden.
Suche unter WPML > String-Übersetzung nach "%1$s" indem Du das Textsuchfeld verwendest.
Kontrolliere nun die Übersetzungen aller betroffenen Strings. Hier ist sehr wahrscheinlich mindesten einmal der Platzhalter "%1$s" nicht korrekt übersetzt worden.
Lass mich daraufhin bitte wissen, ob der betroffene String zuvor alleine automatisch übersetzt wurde und welcher Translation Engine dazu verwendet wurde. Sollte hier allerdings ein Übersetzer lokal gearbeitet haben, dann handelt es sich um einen Benutzerfehler.
der string wurde von deepL übersetzt.
Wir hatten solche Platzhalter-Fehler schon mehrfach.
Seit PHP 8 mündet das immer in einem fatalen Fehler Frontend, was überhaupt nicht gut ist.
Wir hatten bereits ein Ticket zu dieser Problematik bei euch eröffnet mit Bitte um einen Safeguard, damit Platzhalter-Fehler bei auto translate nicht direkt die Seite killen.
Wurde damals abgelehnt.
Schade.
Auto translate geht bei uns wieder.
Konnte den string nun manuell übersetzen.
Wenn ich ihn mit deepL erneut eingereicht habe, wurde wieder falsch übersetzt.
Input: Order now and get a %1$s discount...
Output: Ordina ora e ottieni uno sconto dell'1%...
Wir hatten damit schon häufiger Fehler, wie auch damals schon angemerkt.
Vllt. könnt ihr es unterbinden, dass Übersetzungen mit Platzhalter-Fehler ausgespielt werden. Die erzeugen jedes mal einen fatalen Error, das ist nicht gut.
Gerade, wenn man eine komplett neue Sprache hinzufügt, gibt es immer wieder mehrere solcher Fehler, die man natürlich nicht manuell finden kann, wenn 100.000 string mit einmal im bulk eingereicht werden.
(Anzahl erwarteter Platzhalter & Anzahl Platzhalter in Übersetzung vergleichen, bevor eine Übersetzung gespeichert wird. Ggf. Error irgendwo ausgeben und user informieren, dass eine manuelle Prüfung und Freigabe der Übersetzung zwingend erforderlich ist.)
Gut wäre auch, wenn manuelle Übersetzungen weiterhin möglich sind, auch wenn ATE / translation engines down sind.
Ohne Entwickler hätten wir jetzt 2 Tage einen fatalen Error auf einer wichtigen Produktseite gehabt, weil ATE nicht erreichbar war und die Übersetzung einen Platzhalter-Fehler hatte, den wir nicht bearbeiten konnten.
Ticket kann von mir aus geschlossen werden, habe keine Fragen mehr, ATE geht wieder, damit konnten wir den Fehler beheben.
Wenn ich auf DeepL's Website die Übersetzung ins Italienische teste, sehe ich dein fehlerhaftes Beispiel unter den Alternativen:
versteckter Link
Du könntest hier folgendes tun:
Lege einen Glossareintrag im Übersetzungsmanagement für "%1$s" an. Bei Verwendung von DeepL wird der Glossar bei der automatischen Übersetzung berücksichtigt und das Problem sollte sich auf diese Weise eigentlich lösen lassen.
Beachte dazu, dass das Problem nur dann aufzutreten scheint, wenn man ins Italienische übersetzt.
