When WPML's Translation Dashboard fails, record the exact screen and the action that triggered it before increasing PHP memory. Opening a large content list, calculating a translation estimate and retrieving a translation job are different operations. A blank screen is a symptom, not an explanation.
Match the error to the correct operation
The WPML 5.2.0 changelog describes separate corrections for dashboard timeouts involving translated terms, memory exhaustion while counting words, and memory failures on the Translations screen with persistent object caching. Use these as investigation leads. They do not establish that a particular site's error has been reproduced or fixed.
Write down WordPress, WPML and add-on versions, the PHP runtime used by the web request, the selected languages and the screen name. Include the content-selection scope and approximate dataset size. The PHP configuration used by a command-line process may differ from the one serving the browser request.
Preserve the first useful error
Open the browser Network panel and repeat the failing action once when it is safe. Identify whether the initial document fails or a later request returns an error. Record the timestamp, sanitized endpoint, status and duration. If the interface spins while a request continues running, avoid repeatedly clicking the button and creating more work.
Ask the host for the corresponding PHP and request logs. An allocation-limit message supports a memory investigation. A timeout message requires its own time and caller evidence. A generic 500, 502 or 504 does not, by itself, tell you which component caused the failure or whether increasing a PHP setting would help.
Keep private content, translation text, account tokens and full request payloads out of public tickets. A redacted error line, screen name, installed versions and selected-content count can be more useful than a complete log archive. If public debugging was temporarily enabled by someone else, have the responsible administrator restore the intended protected diagnostic configuration.
A memory allocation error and a timeout are different failure classes. Preserve the exact screen, action and server evidence before selecting a recovery path. Explanatory diagram.
Separate service state from a failing dashboard request
An explicit billing pause is not the same as a PHP process running out of memory. Preserve the existing job rather than creating a replacement translation for the same content. The WPML billing and job-state guide explains how to distinguish a payment-related pause from failed processing and completed content awaiting publication.
Likewise, a Pages admin list rejected because a database statement is too large belongs to the WPML hierarchical-list query-size diagnostic. Do not describe that database restriction as an out-of-memory error unless the actual logs support it.
Build a representative, safe test
Take a restorable backup of files and database. Use a protected staging copy with enough languages, terms and selected content to reproduce the failing operation. Replace unnecessary personal data and disable production emails, payment actions and webhooks. Record which differences from production could affect the result.
First test the smallest useful content selection, then the original failing selection within an agreed resource budget. Do not generate paid translation jobs just to test whether a counting screen loads. Keep the test focused on the observed action and use the vendor-supported workflow for any operation with billing or publication consequences.
After applying the supported coordinated WPML update, repeat the same fixture. Keep the PHP limit unchanged for the first comparison when operationally feasible. Changing the update, memory limit, object cache and content selection at once can produce a working screen without explaining why it works.
What to do if it still fails
For a completed request, Query Monitor can show peak memory and query timing. A request that terminates early may never render that panel, so rely on the host's matching logs instead. Keep comparisons tied to the same screen and action rather than a fast homepage request.
If the environment has genuinely insufficient capacity, agree on a measured adjustment with the host. Increasing a limit is not a substitute for investigating runaway work. Do not prescribe unlimited memory, delete translation tables or flush a production object cache indiscriminately. Record any temporary containment separately from the supported application repair.
Confirm the result beyond the loading spinner
Verify that the intended content appears, languages and filters remain correct, and estimates complete for the tested selection. Check that no duplicate job was created and no draft became public during troubleshooting. Then repeat the original request and review its error and resource evidence.
Document any remaining dataset or concurrency limitation. A small successful test does not guarantee that a larger production selection will fit. HandL WP can trace a failing translation workflow using the screen, error class and representative fixture, while keeping service billing and editorial approval with the appropriate owner.
Sources reviewed November 4, 2026. Examples and diagrams are diagnostic aids, not customer test results.