WPML String Translation helps manage the recurring interface text that appears around WordPress content: plugin messages, theme labels, widget titles, menu text, form instructions and error messages. This is different from translating the text of an ordinary post, page or taxonomy. If a multilingual website displays one language correctly in its main content but leaves buttons, labels or notices untranslated, the missing text may belong to the string translation workflow.
The practical challenge is identifying where a string comes from before choosing a WPML screen. A widget placed inside a page may follow the page translation path, while a legacy widget, an admin setting or JavaScript-based interface text may require registration or scanning. The exact workflow can vary by WPML version, active integrations, widget type, theme and plugin compatibility. WPML does not guarantee automatic discovery of every third-party string, so a structured troubleshooting process is useful.
What WPML String Translation Is—and What It Translates
WPML String Translation is intended for text outside ordinary posts, pages and taxonomies. It covers recurring interface and site-structure text supplied by a theme, plugin or WordPress settings area. Typical examples include a site tagline, widget title, menu label, form instruction, error message or custom message displayed on the front end.
Interface text versus ordinary page content
The first distinction is the location and role of the text. A paragraph entered as part of a page belongs to the page’s translation workflow. A label generated by a plugin, a title saved in a widget, or a message displayed by a form may instead be handled as a string. Theme and plugin interface text is therefore a central use case for String Translation, but not every object should automatically be treated as a generic string.
Some widgets and forms have their own translation path. A widget embedded inside a post or page is translated with the surrounding content. A form may use a dedicated WPML integration. This distinction matters because searching only in String Translation can overlook the workflow intended for a particular component.
Before You Start: Identify the Translation Path
Before searching for an untranslated phrase, identify the object that supplies it. This prevents mixing a page translation with a widget translation or assuming that every form label is registered in the same way. The relevant path can depend on whether the text is in content, a widget area, a form, an administration setting or a front-end script.
A simple object-type checklist
- Post or page content: translate the surrounding post or page rather than treating every phrase as an independent interface string.
- Widget inside content: translate it with the post or page where it was inserted.
- Classic block-based widget area: check the Block section in the Translation Dashboard.
- Legacy widget: look under Other texts (Strings), and use Admin Texts Translation if its saved value is not visible.
- Custom widget: check how the widget is implemented and whether a relevant WPML workflow or integration exists.
- Form: look for a dedicated integration before applying a generic string search.
This classification is a guide rather than a promise of universal compatibility. Available screens and translation paths may vary with the active WPML components, the widget type and the theme or plugin supplying the text.
How to Find and Translate Plugin or Theme Strings
For a typical plugin or theme phrase, begin with registration and front-end discovery. The goal is to make the text available to WPML, find it in the list of other translatable texts, translate it and then confirm the result on the front end. This workflow is documented guidance, not a guarantee that every third-party string will be detected automatically.
The standard registration-and-search workflow
- Confirm that automatic string registration is enabled in the relevant WPML settings.
- Open the front-end page where the untranslated phrase appears, using a non-English language view. Loading the page can allow WPML to identify the string.
- Go to the Translation Dashboard and look in Other texts (Strings). Depending on the available interface, the same work may also be handled from WPML → String Translation.
- Search or filter for the visible phrase, identify the string supplied by the relevant theme or plugin, and send it for translation using the available workflow.
- Open the corresponding front-end view in the target language and check whether the label, message or instruction now appears as expected.
Use the visible text as the starting point, but remember that the stored value may differ from what visitors see. Exact menu labels and available actions can change with the WPML version and active integrations. If the string is not listed after the front-end page has been loaded, continue with the missing-string checks rather than editing theme or plugin source files as a first response.
Translating Widget Text
Widget translation depends on where the widget is placed and how it stores its content. Treating every widget as an item for generic String Translation can lead to the wrong workflow. WPML documents separate paths for widgets inside posts or pages, block-based widget areas, legacy widgets and custom widgets.
Block-based, legacy and custom widgets
When a widget is added inside a post or page, its text follows the translation of that surrounding content. For classic block-based widget areas, use the Block section in the Translation Dashboard. This is different from searching for a legacy widget title among other strings.
Legacy widget text can be selected under Other texts (Strings). If the title or content is missing there, the value may be stored as an administration setting. In that situation, use WPML → String Translation → Admin Texts Translation to add the relevant widget text to the translation workflow. This path can also be relevant to other values saved in the administration area.
Custom widgets require more caution. Their behavior depends on how the widget was implemented and on the available WPML support. Do not assume that a custom widget will be registered or translated automatically. First identify its source and then check whether it follows a documented content, block, string or integration workflow.
Translating Form Labels and Interface Text
Forms often combine several types of text: titles, field labels, sub-labels, instructions, notifications, confirmations and validation messages. The correct procedure depends on the form plugin. WPML String Translation alone should not be presented as a universal form translation system, because a dedicated integration may provide the intended workflow.
When form labels stay untranslated
For WPForms, WPML documents the WPForms Multilingual integration. Its workflow covers form titles, fields, labels, sub-labels, notifications and confirmations. Use the dedicated integration rather than assuming that the generic string list is the only place to translate the form.
If a WPForms label or sub-label remains untranslated, visit the form on the front end in the relevant language. Then search for the remaining text under Other texts (Strings). Loading the form can make the required strings available for registration and translation. Afterward, review the form again, including its messages and confirmation text.
This example should remain specific to WPForms and WPForms Multilingual. It should not be applied identically to every form builder. For another form plugin, first verify whether a dedicated WPML integration exists and whether the plugin’s labels are stored as ordinary content, settings or front-end script text.
Troubleshooting Missing WPML Strings
A missing phrase does not necessarily mean that the search term was entered incorrectly. It may be stored in a setting, loaded only after a relevant page is visited, generated by JavaScript or affected by incomplete compatibility. Work through the least invasive checks first, then use the registration and scanning options that match the type of text.
A practical missing-string checklist
- Check automatic registration. Confirm that the option for registering strings is enabled before loading the relevant page again.
- Load the front end. Visit the page where the phrase appears in a non-English language. A string that has not yet been loaded may not be available in the list.
- Check administration text. Theme and plugin settings, custom messages, widget values and other admin-area text may need to be added through Admin Texts Translation.
- Consider JavaScript. Some front-end text is stored in JavaScript files. WPML documents enabling Detect strings in JavaScript files, visiting the relevant page, scanning the theme or plugin and then translating the registered strings.
- Check the product workflow. The theme, plugin, widget or form may require a dedicated WPML integration, or its compatibility may be incomplete.
- Review the result on the front end. Confirm the translated text in the same view and language where the original phrase appeared.
JavaScript string detection is a specialized troubleshooting step, not a setting to leave enabled without a reason. WPML documents that it may affect site performance and advises disabling it again after the required strings have been registered and translated.
Do not default to editing plugin or theme source files. Registration through Admin Texts Translation, front-end loading, theme or plugin scanning and the documented JavaScript workflow provide more appropriate first troubleshooting paths for website owners.
Performance and Compatibility Checks Before You Finish
Translation work is not complete when a phrase appears in the string list. Check the relevant front-end views in each language used by the website. Review the page, widget area or form where the original text was visible, and verify labels, instructions, notices and messages in their actual context.
Final verification and escalation
If JavaScript detection was enabled, disable it after the required strings have been found and translated, following WPML’s documented caution about possible performance impact. Also review whether a widget or form should have been translated through a dedicated workflow rather than generic String Translation.
Do not assume that every theme, plugin, widget or form builder is fully compatible with WPML. If the documented registration, settings and scanning paths do not expose the required text, check the product’s available WPML integration or compatibility information. Contacting the relevant theme or plugin author can be a practical escalation step when the product’s implementation determines how its text is stored.
WPML String Translation is most useful when treated as a decision-based process: identify the source of the text, choose the matching workflow, register or locate the string, translate it and verify the result on the front end. It is primarily for interface and site-structure text outside ordinary posts, pages and taxonomies. Widgets may follow content, block, legacy or custom paths, while forms may require a dedicated integration. When a string is missing, check registration, front-end loading, admin settings, JavaScript and compatibility instead of assuming automatic detection. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.