Deepglot, explained clearly

Workspace activity

Your weekly digest at a glance

The weekly digest is an opt-in email per user and workspace. It reports new translations and words, manual edits, and runtime translation requests from the previous complete UTC week.

Background translation

How cold WordPress pages warm up

The first request to a cold target-language page may show source content while WP-Cron translates missing segments in the background. Deepglot retains the visitor's localized URL as the later cache target even after WordPress has internally rewritten the request to its source path.

Once the queue and due event are stored, Deepglot makes one non-blocking WP-Cron nudge per request. That nudge is skipped for DISABLE_WP_CRON and while cron is already running. WP Rocket, W3 Total Cache, and LiteSpeed Cache purge completed URLs individually. WP Super Cache exposes only a global purge, so Deepglot waits until the tracked queue is empty and pending pages stay cached. Failed or partial translations remain queued for a later cron retry. Since v0.12.3, an ASCII-safe queue preserves emoji and other four-byte Unicode on legacy WordPress databases. A short atomic lock couples text, URL, and purge reconciliation; stale owners can write only after renewing the lock, damaged queues survive disabled cleanup, and provider calls remain outside. Since v0.12.4, the same protection covers translated cache values: a failed transient write remains queued, does not purge the page, and counts as complete only after exact readback. If a cold request cannot store the coupled queue, its source-language response is not cached so a later request can retry.

Since v0.12.5, Deepglot can scan narrowly configured consent widgets once even when they were inserted before the dynamic footer observer. Normal server-rendered content is not translated again. Internal widget links follow the same language, slug, and infrastructure rules as ordinary page links, and URL values are not sent to the translation provider.

Since v0.12.6, multilingual discovery follows WordPress core viewability for post types. Built-in public pages therefore remain in the sitemap and URL synchronization, while non-viewable builder content types, attachments, and non-queryable taxonomies stay excluded.

Since v0.12.7, Deepglot synchronizes project-wide languages, redirect, disclosure, and automation rules as a versioned SaaS snapshot. WordPress displays the centrally managed values as read-only mirrors and continues serving existing cache hits when fresh automatic translation is disabled.

Since v0.12.8, Deepglot translates ARIA labels on every body element, image tooltips, and the human-readable titles of RSS and Atom feeds. Ordinary link metadata remains excluded from provider requests. Empty or whitespace-only translations are not stored and count as misses in existing legacy cache entries too, so meta descriptions do not disappear.

If every attempted provider reports only a count mismatch for a multi-text root chunk, Deepglot starts direct singleton isolation. It skips redundant binary intermediate shapes and retries each original text through the configured provider chain in input order. The provider-call ceiling is chain length × (chunk size + 1) for a multi-text root, while an original singleton gets one chain; a default eight-text chunk with two providers therefore allows at most 18 provider calls. All root chunks and isolated singletons share the request-wide provider-call concurrency cap (default 12) and a provider-work deadline of at most 100 seconds. PDF translation uses its own 40-second budget from route entry; authentication, upload handling, and PDF preparation reduce the remaining provider time so the 60-second route nominally keeps 20 seconds for completion work. Singleton, call-budget, and deadline mismatches remain terminal. A failing parallel chunk stops new sibling provider calls; timeouts, authentication failures, rate limits, U+0000, and other malformed responses are not retried by this extra isolation path.

Deepglot finishes all bounded root-chunk attempts before starting singleton work. It collects only roots whose complete provider chains produced count mismatches; any other terminal error still aborts siblings immediately. Before calibration, Deepglot compares the remaining deadline with a conservative one-wave reserve: the fastest elapsed duration among the completed full count-mismatch root chains. If that reserve cannot fit, no singleton provider call starts. This root-derived reserve is used only for calibration admission and is never extrapolated across later work. It then runs exactly one global calibration wave containing the first min(request-wide concurrency, total mismatched texts) real singletons through their full provider fallback chains and retains its results. If the shared deadline expires during any admitted singleton wave despite the admission checks, Deepglot returns the same typed deadline error instead of a generic timeout. The remaining work is split into request-wide bounded waves. Before each later wave, Deepglot compares waves still pending × duration of the immediately preceding observed singleton wave with the remaining shared deadline and remeasures after every completed wave. That deadline is the earlier of the local provider-work ceiling and the caller's monotonic absolute deadline; the PDF route passes its route-entry 40-second deadline so authentication, upload handling, and preparation consume the same budget. If the pending work cannot fit, the request stops after the last retained wave and before any further singleton call. API and PDF return the stable 503 code ‘translation_count_mismatch_deadline’; once the first provider call starts, the API conservatively retains its velocity reservation and retains an idempotent same-key 503 for at most 60 seconds. Otherwise, the remaining affected texts continue through the same globally bounded singleton queue, preserving result order and each text's full provider fallback chain.

Before confirming URL synchronization, inspect the sample URLs. If the current safe WordPress request uses HTTPS on the same host, Deepglot changes only the scheme of an internal target still stored with HTTP to HTTPS. Semantic query parameters and fragments are preserved. A foreign request host is not copied. Since v0.12.2, one absolute, query- and fragment-free redirect on the exact same origin and in the requested target language is verified explicitly through separate public and origin probes; automatic redirect following remains disabled. Other redirects remain bounded failures, as do unsafe targets.

Safe text handling

Why Deepglot rejects U+0000

PostgreSQL cannot store the U+0000 null byte in text or JSON. Deepglot therefore rejects it in API, editor, and import input with a validation error before provider calls and before translation content is persisted. Other valid Unicode characters remain unchanged.

If a translation provider response contains U+0000, that result is not stored. A configured fallback provider can take over; if the provider chain still fails, the request ends without attempting translation-content persistence. Logs contain only the boundary, field, count, and provider — never text or URLs.

Bounded retries

Respecting a 429 without a retry storm

HTTP 429 is a temporary limit, not exhausted monthly quota. Deepglot accepts Retry-After as delta seconds or an HTTP date and bounds the delay to 1 to 3,600 seconds. An invalid or missing value uses 60 seconds. This does not raise the hourly threshold. With an Idempotency-Key, concurrent calls share the same 429 response until the remaining Retry-After expires; after that, the request executes again. An active 429 marker stops synchronous visual-editor and email calls and already-due warm-up runs locally until retry_at. Only translation 429 responses set the active marker; configuration and synchronization 429 responses do not. The marker and warmer backoff are bound to the API key and backend. Configuration changes, late responses from the previous configuration, and legacy or unbound markers do not block new translations. The WordPress warmer splits a multi-text 422 batch automatically into halves under the existing six-batch run budget. Every 422 batch shape is tracked for up to one hour by a configuration-bound HMAC fingerprint to drive bounded splitting. Only a text that still returns 422 alone—text that is still too large alone—is blocked from automatic resend for up to one hour; no raw text, API keys, or URLs are stored. Normal following batches continue, and a key or backend change heals the marker immediately. API requests and PDFs must still be split into smaller inputs by clients. This browser behavior receives a new public asset version in v0.12.1; preparing or publishing a package does not automatically update customer sites.

WordPress

What WordPress v0.11.4–v0.11.7 changed

These four releases stabilize URL resolution, large cold pages, and trusted site-specific post-processing. They do not replace a production approval: publishing a package does not automatically install or update a customer plugin.