Reference

Troubleshooting

Start at Gloty → Overview. It runs live health checks against your specific site and usually names the problem before you have to go looking.

Read the Overview screen first

Each issue has a severity and a direct action link. These are the checks Gloty runs:

Nothing is being translated

Work through these in order:

1. Is the site connected?

   Gloty → Overview will show Translator service not connected if the service URL or API token is missing. Re-run the connection step in the setup wizard.

2. Is there a license, and does it have quota?

   Open Gloty → Billing and click Refresh status. Confirm the plan is active and the usage bar is not full.

3. Is there anything in the queue?

   On Gloty → Sync, check the translations queued to send count. If it is zero, run a content scan — nothing has been discovered yet.

4. Force a dispatch

   Click Translate now. If jobs appear and complete, the pipeline is healthy and your problem is cron — see the next section.

5. Check outbound connectivity

   Some hosts and security plugins block outbound HTTPS. If dispatch fails immediately with a network error, ask your host whether outbound requests are restricted.

It only works when I click "Translate now"

This is the classic symptom of WP-Cron not firing. WordPress cron is triggered by page visits, so on a low-traffic site it barely runs.

The fix is a real cron. Disable WP-Cron in wp-config.php:

define( 'DISABLE_WP_CRON', true );

Then run it from the system scheduler every minute:

* * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

A one-minute uptime-monitor ping at the same URL works just as well. Most managed WordPress hosts offer a cron setting in their control panel.

Jobs are stuck in "processing"

A dispatched batch waits for the service to call back. If that webhook is blocked — by a firewall, a security plugin, or a staging-site password — the batch sits in processing.

Gloty already handles this: a reconciler polls for results every five minutes, and the Overview screen triggers a reconciliation when you open it. Stuck jobs normally resolve themselves within minutes.

If they do not:

• Confirm your site is publicly reachable over HTTPS. Webhooks cannot reach a local or password-protected site — polling is the only path there, which is slower but works.
• Check whether a security plugin or WAF blocks POST requests to the WordPress REST API.
• Re-queue the affected rows from Gloty → Translations using Translate selected.

Language URLs return 404

1. Confirm the language is active on Gloty → Languages, not merely configured.
2. Go to Settings → Permalinks and click Save. This rebuilds WordPress's rewrite rules.
3. Confirm you are not on plain permalinks. Subdirectory language URLs require a pretty permalink structure; Gloty sets one if needed, but a later change can undo it.

The page still shows the old text

Almost always a cache. In order of likelihood:

• Page cache. Gloty purges each language URL when its translations change, but a CDN in front of your site may hold its own copy. Purge the CDN.
• Browser cache. Try a private window.
• The string is not translated yet. Search for it on Gloty → Translations — if it is Pending, it is waiting in the queue.
• The translation is stale. If you edited the source, the old translation is still served and the row is flagged stale. Re-queue it.

Some parts of the page stay in English

The queue keeps filling with junk strings

Some themes and plugins pass dynamically assembled text through the translation functions — brand lists, comma-joined names, generated labels. Each variant looks like a unique string.

Gloty recognises and skips generated proper-noun lists, caps how many new strings a single page render may add, and ignores empty strings, numbers, prices, and over-long text. 1.10.1 / 1.11.1

If something still gets through, add a CSS selector for the offending region to Exclusion selectors in Settings. Deleting rows alone will not help while the string is still being captured.

A manual edit was overwritten

This should not happen: rows marked Manually edited are protected from machine sync. Check the row's status on Gloty → Translations. If it says Synced, the edit was not saved — an empty translation is rejected, so make sure the field had content when you saved.

Translated pages feel slow

• Gloty loads all of a page's translations in one query and holds them in memory for the request, so per-string lookups are not your bottleneck. 1.14.0
• The biggest win on a busy site — especially WooCommerce — is a persistent object cache (Redis or Memcached). Without one, every uncached render re-reads from the database.
• A page cache in front of that means most visitors never trigger a render at all.

A page broke after translation

Gloty is built to fail safe. Full-page post-processing is wrapped so any error results in the original page being served, and a translation whose printf placeholders do not match the source is rejected in favour of the source text — so a mistranslated %1$s cannot fatal a page. 1.5.1 / 1.5.2

If you still hit a broken page, deactivate Gloty to confirm it is the cause, then report it with the URL, the language, and your PHP error log.

Reporting a problem

Include:

• Gloty version, WordPress version, PHP version.
• A screenshot of Gloty → Overview, including any issues listed.
• The Technical details block from Gloty → Sync if the problem involves scanning.
• The correlation ID of an affected job, if the problem involves a specific batch.
• The exact URL and language where you see the problem.

Last updated 26 July 2026 · Gloty 1.15.2