Deepglot verständlich erklärt

Workspace-Aktivität

Der Wochenrückblick auf einen Blick

Der Wochenrückblick ist eine freiwillige E-Mail pro Benutzer und Workspace. Er zeigt neue Übersetzungen und Wörter, manuelle Bearbeitungen und Laufzeit-Übersetzungsanfragen aus der letzten vollständigen UTC-Woche.

Hintergrundübersetzung

Wie kalte WordPress-Seiten warm werden

Der erste Aufruf einer kalten Zielsprachenseite darf Quelltext zeigen, während WP-Cron fehlende Segmente im Hintergrund übersetzt. Deepglot behält dabei die lokalisierte URL des Besuchers als späteres Cache-Ziel, auch wenn WordPress intern bereits auf den Quellpfad umgeschrieben hat.

Sobald Warteschlange und fälliges Ereignis gespeichert sind, stößt Deepglot pro Anfrage einmal nicht blockierend WP-Cron an. Bei DISABLE_WP_CRON oder während eines Cron-Laufs bleibt dieser Anstoß aus. WP Rocket, W3 Total Cache und LiteSpeed Cache leeren fertig übersetzte URLs einzeln. WP Super Cache bietet nur einen globalen Purge; Deepglot wartet deshalb, bis die verfolgte Warteschlange leer ist, damit ausstehende Seiten im Cache bleiben. Fehlgeschlagene oder unvollständige Übersetzungen bleiben vorgemerkt und können bei einem späteren Cron-Lauf erneut versucht werden. Seit v0.12.3 bewahrt eine ASCII-sichere Warteschlange auch Emoji und anderes Vier-Byte-Unicode auf älteren WordPress-Datenbanken. Eine kurze atomare Sperre koppelt Text-, URL- und Purge-Abgleich; veraltete Besitzer dürfen nur mit erneuerter Sperre schreiben, beschädigte Warteschlangen bleiben auch beim Deaktivieren erhalten und die eigentlichen Anbieteraufrufe laufen außerhalb. Seit v0.12.4 gilt derselbe Schutz für übersetzte Cachewerte: Ein fehlgeschlagener Transient-Schreibvorgang bleibt vorgemerkt, löst keinen Seiten-Purge aus und wird erst nach exaktem Readback als abgeschlossen gewertet. Kann ein kalter Aufruf die gekoppelte Warteschlange nicht speichern, wird seine Quelltext-Antwort nicht gecacht, damit ein späterer Aufruf es erneut versuchen kann.

Seit v0.12.5 kann Deepglot eng konfigurierte Consent-Widgets einmalig erfassen, auch wenn sie bereits vor dem dynamischen Footer-Observer eingefügt wurden. Normale servergerenderte Inhalte werden dabei nicht erneut übersetzt. Interne Links im Widget folgen denselben Sprach-, Slug- und Infrastrukturregeln wie normale Seitenlinks; URL-Werte werden nicht an den Übersetzungsanbieter gesendet.

Seit v0.12.6 folgt die mehrsprachige Seitenerkennung der WordPress-Core-Sichtbarkeit für Beitragstypen. Öffentliche Standardseiten bleiben dadurch in Sitemap und URL-Synchronisierung enthalten, während nicht sichtbare Builder-Inhaltstypen, Anhänge und nicht öffentlich abfragbare Taxonomien ausgeschlossen bleiben.

Seit v0.12.7 synchronisiert Deepglot die projektweiten Sprachen, Weiterleitungs-, Offenlegungs- und Automatikregeln als versionierten SaaS-Snapshot. WordPress zeigt die zentral verwalteten Werte als schreibgeschützte Spiegel und liefert vorhandene Cache-Treffer auch dann aus, wenn neue automatische Übersetzungen deaktiviert sind.

Seit v0.12.8 übersetzt Deepglot ARIA-Beschriftungen auf allen Elementen im Seiteninhalt sowie Bild-Tooltips und die sichtbaren Titel von RSS- und Atom-Feeds. Normale Link-Metadaten bleiben von Anbieteranfragen ausgeschlossen. Leere oder ausschließlich aus Leerraum bestehende Übersetzungen werden nicht gespeichert und gelten auch in bestehenden, älteren Cacheeinträgen als Fehltreffer, damit Metabeschreibungen nicht verschwinden.

Melden alle versuchten Anbieter bei einem mehrteiligen Ausgangsstapel nur eine Abweichung bei der Ergebnisanzahl, startet Deepglot eine direkte Einzeltext-Isolierung. Redundante binäre Zwischenstufen entfallen; jeder ursprüngliche Text durchläuft die konfigurierte Anbieterkette in seiner Eingabereihenfolge. Für einen mehrteiligen Ausgangsstapel lautet die Anbieteraufrufgrenze Kettenlänge × (Stapelgröße + 1); ein ursprünglicher Einzeltext durchläuft die Kette einmal. Beim Standardfall mit acht Texten und zwei Anbietern sind das höchstens 18 Anbieteraufrufe. Alle Ausgangsstapel und isolierten Einzeltexte teilen sich die anfrageweite Parallelitätsgrenze von standardmäßig 12 und eine gemeinsame Anbieterarbeitsfrist von höchstens 100 Sekunden. Für PDF-Übersetzungen läuft ab Routeneintritt ein eigenes Budget von 40 Sekunden; Authentifizierung, Upload-Verarbeitung und PDF-Vorbereitung verkürzen die verbleibende Anbieterzeit, damit für Abschlussarbeiten der 60-Sekunden-Route nominell 20 Sekunden bleiben. Abweichungen bei einem Einzeltext sowie am Aufruf- oder Zeitlimit bleiben endgültige Fehler. Fehler eines parallelen Stapels stoppen neue Anbieteraufrufe von Geschwistern; Zeitüberschreitungen, Authentifizierungsfehler, Ratenlimits, U+0000 und andere ungültige Antworten werden dadurch nicht zusätzlich wiederholt.

Deepglot wertet alle begrenzten Ausgangsstapel aus, bevor Einzeltextaufrufe beginnen. Gesammelt werden nur Ausgangsstapel, deren vollständige Anbieterkette ausschließlich Abweichungen bei der Ergebnisanzahl geliefert hat; jeder andere endgültige Fehler bricht Geschwister weiterhin sofort ab. Vor dem Start der Kalibrierung vergleicht Deepglot die Restfrist mit einer konservativen Reserve für eine Welle: der kürzesten gemessenen Gesamtdauer unter den vollständig abgeschlossenen Ausgangsketten mit reinen Ergebnisanzahl-Abweichungen. Passt diese Reserve nicht, beginnt kein Einzeltext-Anbieteraufruf. Diese aus Ausgangsstapeln abgeleitete Reserve dient nur der Zulassung der Kalibrierung und wird nie auf spätere Arbeit hochgerechnet. Danach führt Deepglot genau eine globale Kalibrierungswelle mit den ersten min(anfrageweite Parallelität, Anzahl abweichender Texte) echten Einzeltexten durch die vollständige Anbieter-Fallbackkette aus und übernimmt deren Ergebnisse. Läuft die gemeinsame Frist trotz der Zulassungsprüfungen während einer bereits zugelassenen Einzeltextwelle ab, gibt Deepglot denselben typisierten Fristfehler statt einer allgemeinen Zeitüberschreitung zurück. Die verbleibende Arbeit wird in anfrageweit begrenzte Wellen geteilt. Vor jeder späteren Welle vergleicht Deepglot Anzahl noch ausstehender Wellen × gemessene Dauer der unmittelbar vorherigen Einzeltextwelle mit der verbleibenden gemeinsamen Frist und misst nach jeder abgeschlossenen Welle neu. Maßgeblich ist die frühere Frist aus lokaler Anbieterarbeitsgrenze und monotoner absoluter Aufruferfrist; die PDF-Route übergibt ihre beim Routeneintritt beginnende 40-Sekunden-Frist, sodass Authentifizierung, Upload-Verarbeitung und Vorbereitung dasselbe Budget verbrauchen. Passt die ausstehende Arbeit nicht mehr, endet die Anfrage nach der letzten übernommenen Welle und vor jedem weiteren Einzeltextaufruf. API und PDF antworten mit dem stabilen 503-Code „translation_count_mismatch_deadline“; ab dem ersten Anbieteraufruf behält die API ihre Geschwindigkeitslimit-Reservierung konservativ bei und speichert eine idempotente 503-Antwort für denselben Schlüssel höchstens 60 Sekunden. Andernfalls laufen die verbleibenden betroffenen Texte durch dieselbe global begrenzte Einzeltextwarteschlange; Ergebnisreihenfolge und vollständige Anbieter-Fallbackkette bleiben erhalten.

Prüfe vor dem Bestätigen einer URL-Synchronisierung die Beispiel-URLs: Läuft die aktuelle sichere WordPress-Anfrage über HTTPS auf demselben Host, korrigiert Deepglot bei einer noch mit HTTP gespeicherten internen Ziel-URL nur das Schema auf HTTPS. Semantische Query-Parameter und Fragmente bleiben erhalten. Ein fremder Request-Host wird nicht übernommen. Mit v0.12.2 wird eine absolute, query- und fragmentfreie Weiterleitung auf exakt derselben Origin und in derselben Zielsprache mit getrennten öffentlichen und Origin-Prüfungen explizit verifiziert; automatisches Folgen bleibt deaktiviert. Andere Weiterleitungen bleiben begrenzte Fehler; dasselbe gilt für unsichere Ziele.

Sichere Textverarbeitung

Warum Deepglot U+0000 ablehnt

PostgreSQL kann das NUL-Zeichen U+0000 weder in Text noch in JSON speichern. Deepglot lehnt es deshalb in API-, Editor- und Import-Eingaben vor Anbieteraufrufen und vor der Persistenz von Übersetzungsinhalten mit einem Validierungsfehler ab. Andere gültige Unicode-Zeichen bleiben unverändert.

Enthält stattdessen die Antwort eines Übersetzungsanbieters U+0000, wird dieses Ergebnis nicht gespeichert. Ein konfigurierter Ersatzanbieter kann übernehmen; schlägt auch die Anbieterkette fehl, endet die Anfrage ohne Versuch, Übersetzungsinhalte zu persistieren. Protokolliert werden nur Grenze, Feld, Anzahl und Anbieter — niemals Text oder URL.

Begrenzte Wiederholungen

429 ohne Wiederholungsschleife beachten

Ein HTTP 429 ist eine vorübergehende Begrenzung, kein verbrauchtes Monatskontingent. Deepglot übernimmt Retry-After als Sekundenwert oder HTTP-Datum und begrenzt die Wartezeit auf 1 bis 3.600 Sekunden. Fehlt ein gültiger Wert, gelten 60 Sekunden. Das Stundenlimit selbst wurde dabei nicht angehoben. Mit einem Idempotency-Key teilen gleichzeitige Aufrufe dieselbe 429-Antwort bis zum verbleibenden Retry-After; danach wird die Anfrage neu ausgeführt. Ein aktiver 429-Marker stoppt synchrone Visual-Editor- und E-Mail-Aufrufe sowie bereits fällige Warmup-Läufe lokal bis retry_at. Nur Translation-429-Antworten setzen den aktiven Marker; 429-Antworten von Konfigurations- und Synchronisationsaufrufen tun das nicht. Marker und Warmer-Wartezustand sind an API-Schlüssel und Backend gebunden. Konfigurationswechsel, verspätete Antworten der alten Konfiguration und alte ungebundene Marker blockieren keine neuen Übersetzungen. Der WordPress-Warmer teilt einen mehrteiligen 422-Stapel unter dem bestehenden Laufbudget von sechs Stapeln automatisch binär. Jede 422-Stapelform wird bis zu einer Stunde mit einem konfigurationsgebundenen HMAC-Fingerabdruck nachverfolgt und steuert so die begrenzte Aufteilung. Nur ein Text, der allein weiterhin 422 liefert – also ein einzeln zu großer Text –, wird bis zu einer Stunde von automatischen Wiederholungen ausgeschlossen; dabei werden keine Rohtexte, API-Schlüssel oder URLs gespeichert. Normale folgende Stapel laufen weiter, und ein Schlüssel- oder Backendwechsel heilt den Marker sofort. API-Anfragen und PDFs müssen Clients weiterhin kleiner teilen. Dieses Browser-Verhalten erhält mit v0.12.1 eine neue öffentliche Asset-Version; ein vorbereitetes oder veröffentlichtes Paket aktualisiert Kunden-Websites nicht automatisch.

WordPress

Was v0.11.4 bis v0.11.7 gelöst haben

Diese vier Releases stabilisieren URL-Auflösung, große kalte Seiten und vertrauenswürdige Site-spezifische Nachbearbeitung. Sie ersetzen keine Produktionsfreigabe: Ein veröffentlichtes Paket installiert oder aktualisiert kein Kunden-Plugin automatisch.