Start here
How Gloty works
Gloty separates translating from serving. Translation is slow, remote, and happens in the background. Serving is fast, local, and happens on every page view. Almost everything else in the plugin follows from that split.
- Discover Translatable strings are found as pages render and during a content scan.
- Queue Each new string becomes a pending row in your database, per target language.
- Dispatch A background job batches pending rows and sends them to the translation service.
- Deliver Finished translations return by webhook, with polling as a fallback.
- Serve Pages read translations from the local cache. No remote call at render time.
Where strings come from
A WordPress page is assembled from several very different sources, so Gloty runs several capture paths. Each translation row records which path it came from, shown in the Context column on Gloty → Translations.
| Source | What it covers | Shown as |
|---|---|---|
| Interface strings | Text your theme, plugins, and WordPress core pass through the translation functions — buttons, labels, form messages, WooCommerce interface copy. | Theme / UI string |
| Content entities | Posts, pages, custom post types and taxonomy terms, read from WordPress itself. Long post content is split into block-safe segments rather than one giant string. | Post / Term |
| Theme & Customizer text | Text that is neither post content nor a translatable interface string — a hero headline or feature box typed into the Customizer, for example. Captured from the rendered page. 1.5.0 | Theme / UI string |
| SEO metadata | Titles, meta descriptions, and social tags — including Yoast SEO and Rank Math fields when those plugins are active. 1.8.0 | Site option / meta |
What is deliberately not captured
Capture is guarded so a single unusual page cannot flood your queue and burn quota. Gloty skips:
- Empty strings, pure numbers, and prices.
- Text over a maximum length.
- Machine-generated lists of proper nouns — for example a "shop by brand" widget producing "Chanel & Amouage & Creed Fragrances", which is unique on every page and never worth translating. 1.10.1 / 1.11.1
-
Admin screens, feeds, previews, REST responses, JSON payloads,
and
admin-ajaxrequests. These are usually data, not visitor-facing text.
There is one deliberate exception to the AJAX rule: WooCommerce store AJAX fragments — the mini-cart drawer, free-shipping bar, and checkout order review — are visitor-facing HTML, so they are translated. 1.15.0
There is also a per-page cap on how many new strings one render may add, so a runaway template degrades gracefully instead of filling the queue.
From queue to translation
Each pending row is one source string in one target language. A site with 500 strings and two target languages has 1,000 rows to fill.
Batching and dispatch
A background job runs roughly once a minute and sends several batches per run. Two settings control the rate:
gloty_dispatch_batches_per_tick filter.
1.3.0
Clicking Translate now on Gloty → Sync dispatches a larger burst immediately instead of waiting for the next scheduled run.
Delivery
When the service finishes a batch it calls a signed webhook on your site, and the results are written straight into your database. Each request carries an HMAC-SHA256 signature computed with a secret generated during setup and known only to your site and the service; requests that fail verification are rejected.
Because webhooks can be blocked by firewalls or security plugins, Gloty also polls for results every five minutes. If the webhook never arrives, the poller reconciles the job anyway — you may just wait a few minutes longer.
Deduplication
Identical source text in the same language pair is translated once and reused everywhere, even when the two occurrences were found by different capture paths. A database constraint enforces this, so you never pay to translate the same sentence twice. 1.7.0
Terms in your glossary that match a whole string are never sent to the translator at all — they are applied locally, which keeps brand names exact and costs nothing.
How a translated page is served
When a visitor requests /de/some-page/, Gloty resolves
the language from the URL and then does only local work:
- One bulk read. All translations that page needs are loaded in a single query and held in memory for the rest of the request, instead of one lookup per string. 1.14.0
- Substitution in place. Titles, content, terms, menus, interface strings, and metadata are swapped as WordPress renders them. Text-node-level replacement is used for captured theme text so scripts, markup, and product data stay byte-for-byte identical.
-
Language-correct output. The page declares
<html lang="de">, canonical andhreflangtags, and internal links keep the/de/prefix. -
Fail-safe. Post-processing is wrapped so that if
anything goes wrong the original page is served rather than a
broken one. A separate guard checks that a translated format
string still has the same placeholders as the source — a
mistranslated
%1$scan never take a page down. 1.5.2
Nothing is fetched remotely during a render. If a string has no translation yet, the source text is shown and the string is registered for translation. The visitor never waits on the translation service.
Page caching
Gloty purges cached pages when their translations change — when new results arrive, when you save a manual edit, or when you delete a row. Each language-prefixed URL is purged, not just the canonical permalink. LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, Cache Enabler, WP Fastest Cache, and SiteGround caching are handled automatically; custom and CDN caches can hook the purge actions listed in the developer reference. 1.3.2
Statuses and terminology
Translation row status
| Status | Meaning |
|---|---|
| Pending | Discovered and queued, not yet sent to the translation service. |
| Processing | Sent in a batch; waiting for the result. |
| Synced | Machine translation delivered and in use. May be replaced by a later re-sync. |
| Manually edited | Edited by a human and protected — machine sync will not overwrite it. |
Job status
A job is one dispatched batch, listed under Recent jobs on Gloty → Sync. Jobs move through queued → processing → completed, or end as failed or cancelled.
Stale
A translation is stale when its source text has changed since the translation was produced. Gloty keeps serving the existing translation — a slightly outdated translation beats an untranslated page — and flags the row so you can re-queue it. Filter by Stale only on the Translations screen to find them.
What leaves your site
Being precise about this matters, so:
- Translations are stored only in your database. Gloty's tables live alongside your WordPress data and are covered by your normal backups. Nothing is required to be fetched from a remote service to render a page.
- The text being translated is sent to the Gloty translation service while a batch is in flight, which passes it to the translation engine selected for your plan. This is the only outbound content transfer, and it happens once per unique string per language.
- Your site also reports usage — character counts and license state — so quota and plan limits can be enforced.
- Visitor data is never sent. Translation batches contain source strings, not page views, IP addresses, or customer data.