Using Gloty
Scanning & sync
Gloty → Sync is the engine room: step one finds the text on your site, step two turns it into translations. Most of the time it runs itself — this page is for when you want to watch it, speed it up, or understand what it is doing.
Step 1 · Scan content
The content scan walks your site's published content and registers everything translatable it finds. It runs in checkpointed batches, so it works on shared hosting and can be paused and resumed without losing its place.
What the scan covers
- All public post types — posts, pages, products, and any custom post type registered as public. Media attachments are skipped.
- All public taxonomy terms — categories, tags, product categories, custom taxonomies.
The scan runs in two phases: posts first, then terms. The progress panel shows overall progress and progress within the current phase.
The scan is not the only discovery path. Interface strings from your theme and plugins, and text typed into the Customizer, are discovered when a page renders — not by the scan. That is why a freshly scanned site keeps finding new strings as you browse it.
Scan modes
All three modes walk the same content; they differ in how many items each batch processes, which trades speed against load on your server.
| Mode | Items per batch | Use when |
|---|---|---|
| Quick scan | 10 | A modest host, or you want the lightest possible footprint while the site is busy. |
| Incremental rescan | 15 | Picking up content added since the last scan. |
| Full backfill Default | 20 | First run on an existing site, or any time you want the whole catalogue covered as fast as possible. |
Re-running a scan is always safe. Content is registered by a hash of its source text, so scanning the same post twice updates the existing record instead of creating a duplicate or re-spending quota.
Controls
The Technical details disclosure shows the raw state — mode, current phase, checkpoint offset, items discovered and queued in this run, and the total number of registered sources. Include these values if you ever report a scanning problem.
Step 2 · Generate translations
Scanning fills the queue; this step empties it. The panel shows how many translations are queued to send — that is pending rows, counted per language, so two target languages produce two rows per source string.
Click Translate now to dispatch a burst of batches immediately. Otherwise the background job picks them up on its own schedule.
Throughput
Two levers control how fast the queue drains:
| Lever | Where | Default |
|---|---|---|
| Dispatch batch size | Gloty → Settings | 40 strings per batch (range 1–500). 100–250 suits a large initial translation. |
| Batches per background run |
gloty_dispatch_batches_per_tick filter
|
5 |
WordPress cron only fires when
someone visits your site.
On a quiet site translations trickle out slowly, no matter how
large your batch size. For steady throughput, disable WP-Cron
and point a real system cron — or a one-minute uptime ping — at
wp-cron.php. The translator is fast; it just needs
to be fed.
Background schedule
| Job | Frequency | What it does |
|---|---|---|
| Dispatch | Every minute | Sends pending batches to the translation service. |
| Reconcile | Every 5 minutes | Polls for results that never arrived by webhook — the safety net when a firewall blocks incoming requests. |
| License check | Daily | Refreshes plan, quota, and available engines. |
Recent jobs
Each row is one dispatched batch, with its status, segment count, language, correlation ID, and creation time.
| Status | Meaning | What to do |
|---|---|---|
| Queued | Created, not yet sent. | Nothing — the next run will pick it up. |
| Processing | Sent; awaiting results. | Normally a few seconds to a couple of minutes. Batches stuck for a long time raise a warning on the Overview screen. |
| Completed | Results delivered and stored. | Nothing. |
| Failed | The batch could not be translated — commonly an exhausted quota or a connectivity problem. | Check Gloty → Overview for the reason, fix it, then Retry the job. |
| Cancelled | Stopped before completing. | Retry it if you still want those strings translated. |
Individual jobs can be acted on directly: Retry re-sends a batch that failed or was cancelled, and Cancel stops one that is no longer wanted. Retrying is the right first move after fixing the cause of a failure — it is more precise than re-queuing rows from the Translations screen.
The correlation ID ties a batch on your site to the same batch on the translation service. Quote it when contacting support about a specific job.
Event log
Below the job list, the collapsible Event log is the audit trail of what Gloty has actually done — useful when a job failed and the status alone does not say why. Filter it by type:
| Type | Records |
|---|---|
| Sync | Batches being dispatched to the service. |
| Webhook | Results arriving back. Silence here while jobs sit in processing points at a blocked webhook. |
| Translation | Individual translation rows being written or changed. |
| Scan | Content scan progress and checkpoints. |
Keeping up with new content
Once the initial pass is done, Gloty keeps itself current without a scan:
- Publishing or updating a post or term re-registers it automatically, and its translations are marked stale so you can see what changed.
- New text found that way is queued for every active target language straight away, and the background job dispatches it on its next run. No setting to enable, and no manual step.
- Run an Incremental rescan after a bulk import or a migration, when many items changed without going through the normal editor flow.