WPML Strings Not Showing After Scan: How to Find and Fix Missing Theme Strings

You scan your theme in WPML, wait for the confirmation, open String Translation—and find nothing useful. It feels like WPML has missed your theme entirely. But when WPML strings are not showing after scan, the scan is often doing exactly what it can: detecting only the strings WordPress code exposes in a format WPML recognizes.

The problem may be hiding in plain sight: a missing or mismatched text domain, text hardcoded outside translation functions, template code WPML cannot parse, or strings loaded from a source the scan never reaches. Even a correct fix can appear to fail when cached translation files or stale configuration are still in the way.

A completed scan is not proof that every visible label is translatable. The key is to stop scanning blindly and trace where the missing text actually comes from—because once that source is clear, the right fix is usually far more straightforward than it first appears.

Why WPML Finds No Strings After Scanning a Theme

What the WPML theme scan actually looks for

A theme scan is not a search engine for every word visible on your site. WPML’s String Translation scan looks for text that the theme developer has explicitly prepared for translation using WordPress internationalization functions, such as __(), _e(), or esc_html__(), along with the theme’s registered text domain.

For example, a label written as __(‘Read more’, ‘my-theme’) can be detected and registered. But a template containing plain HTML such as <span>Read more</span> gives WPML nothing to register. The text may appear on the front end, yet it is hardcoded rather than translatable. This is the central misunderstanding behind many reports of wpml strings not showing after scan.

Common reasons the scan returns zero or incomplete results

A zero-result scan does not automatically mean WPML is broken. It usually means the strings are outside the scanner’s expected pattern or belong somewhere else.

• Hardcoded labels: Text is written directly into PHP, HTML, JavaScript, or template files without WordPress translation functions.
• Missing or inconsistent text domains: A theme may declare one domain but use another in its translation calls, preventing reliable registration.
• The wrong theme was scanned: Check whether the live text comes from the active child theme, the parent theme, or a separate template pack.
• Dynamic output: Labels assembled from variables, database values, or custom fields may not exist as a fixed string in a file.
• Stored settings and builder data: Theme options, Elementor templates, and similar page-builder content are saved in the database, not necessarily in the theme code WPML scans.
• Nonstandard template formats: Twig-based or heavily compiled templates can be difficult for a file scanner to interpret consistently.

Theme strings, content strings, and plugin strings are different sources

Before rescanning, identify the source of the missing phrase. A “Checkout” label may come from WooCommerce, not the theme. A heading inside an Elementor section is page content, not a String Translation entry. A footer copyright line may be a theme option that requires WPML’s admin-text registration workflow.

This distinction saves time. Scan the active theme for its interface labels; scan WooCommerce or another plugin for plugin-owned strings; translate posts, pages, and builder templates through WPML’s content translation tools. If a string was never marked translatable in the theme code, repeated scans will not force it into String Translation—the code or registration method must change first.

How to Force a Proper WPML String Scan Step by Step

A successful scan can still return no useful strings. That is the frustrating part of diagnosing wpml strings not showing after scan: the problem is often not WPML itself, but where and how the label is generated.

Confirm String Translation and the active theme

First, confirm that the WPML String Translation component is active. Then check Appearance > Themes and identify both the active child theme and its parent theme. A label may live in either directory. Scan the folder that actually contains the template or function producing the missing text; scanning only the parent theme will not find a child-theme override.

Rescan, then widen your String Translation search

Run the theme scan again from WPML’s theme and plugin localization settings. In String Translation, search for the exact source wording, including punctuation where possible. Remove restrictive domain and translation-status filters first. Newly found strings are easily missed when the screen is limited to a different text domain, a specific language, or only untranslated entries.

Check for WordPress translation functions

A PHP source scan detects gettext calls, not every visible sentence. Translation-ready code generally looks like __(‘Label’, ‘theme-textdomain’) or esc_html__(‘Label’, ‘theme-textdomain’). By contrast, a hardcoded snippet such as <span>Label</span> gives WPML nothing to register. The fix belongs in the theme code: wrap user-facing text in the appropriate localization function, then scan again.

Verify the text domain is consistent

The theme header, gettext calls, and translation-file naming must use the same text domain. A call using my-theme will not reliably connect to files and settings built around mytheme. Themes using standard WordPress localization should also load their text domain correctly, typically during theme setup. One mismatched hyphen can make an otherwise valid translation invisible.

Treat Twig, JavaScript, and dynamic labels as separate cases

A conventional PHP scan is not a universal content detector. Twig templates, JavaScript bundles, custom-field values, database options, and labels assembled at runtime may require WPML configuration, a supported JavaScript or template localization pattern, or explicit WPML string registration. If the text is stored in an option rather than a theme file, repeated source scans will not solve it.

Clear caches and rule out stale files

Finally, clear WordPress page caches, object cache, CDN cache, and your browser cache. Verify that you edited the deployed server file rather than a local copy. After theme updates, also recheck child-theme overrides and compiled assets: a build process can replace the text visitors see even when the source file you scanned looks correct.

When a Rescan Still Does Not Show the String

Register custom or option-based strings explicitly

A scan can only find text that exists in code in a form WPML can recognize. It cannot reliably discover a value stored in the database, assembled at runtime, or entered through a theme settings panel. That is why wpml strings not showing after scan is often a registration problem rather than a scanning problem.

For custom settings, theme options, and dynamic labels, developers should register the value explicitly through WPML’s supported string-registration hooks or APIs, then translate it in String Translation. A “Sale ends Friday” banner saved in an options table, for example, will not appear merely because its output template is scanned. Register the option when it is saved or loaded, give it a clear context and name, and WPML has a stable translation target.

Fix translation readiness in a custom theme

Repeated scans do not repair a theme that is not prepared for translation. The durable fix is in the source code.

• Replace hardcoded interface text with WordPress gettext functions such as __(), _e(), or their escaping equivalents.
• Use one valid, consistent text domain throughout the theme; a mismatched domain can make otherwise correct strings invisible.
• Preserve placeholders exactly, including %s, %d, and numbered variants such as %1$s.
• Ensure the theme’s translation files are available and its text domain is loaded correctly.
• Test one change at a time: update the template, rescan, and confirm the string appears before moving on.

This method is slower than clicking Scan three times. It is also the one that works. If a label is generated by JavaScript, Twig, a page builder, or a remote API, check that layer too; PHP theme scanning may never index it.

Collect the details WPML support will need

When the string still cannot be found, a precise report saves days of back-and-forth. Include:

• the exact source string and its expected language;
• theme, child theme, WordPress, and WPML versions;
• the template or file path where the text originates;
• the relevant code snippet, including its text domain;
• screenshots of the scan settings and String Translation results; and
• a staging-site reproduction, where possible.

Translate registered WPML strings more efficiently with LATW AI Translator for WPML

For sites already running WPML, LATW AI Translator for WPML can translate registered content and WPML String Translation strings inside WPML’s existing workflow. It is an add-on, not a standalone multilingual plugin, so an active WPML installation is required. You choose an AI or machine-translation engine, and requests go directly from WordPress to the selected provider rather than through intermediary plugin servers.

Turn a Missing-String Problem into a Clear Diagnosis

When WPML strings are not showing after a scan, another scan alone rarely changes the outcome. Treat the missing text as a clue: confirm that it belongs to the active theme or plugin, scan the correct source, use the right String Translation filters, and then inspect whether the string is genuinely prepared for translation. Text that bypasses gettext, uses the wrong text domain, or is generated dynamically will not become translatable simply because WPML has been asked to scan again.

Work through the checks in that order, then register dynamic values explicitly where code cannot expose them automatically. That approach fixes the cause rather than filling String Translation with noise—and leaves you with a site whose language can grow as reliably as its content.