WPML String Translation - WordPress Plugin

Guide to Configuring and Using WPML String Translation

WPML String Translation is not for translating regular posts and pages. It is for the WordPress text that lives around your content: the site tagline, widget labels, form messages, theme strings, plugin settings, menu items, admin text, and individual technical phrases. Those "small" strings are exactly why a multilingual site often feels unfinished: the pages are already translated, but a button, notice, or footer label is still showing in the original language.

This guide focuses on practical use rather than marketing copy: what to check before installation, where to go after activation, how to find strings, why some text does not appear automatically, how to translate strings from theme and plugin settings, what to do with JavaScript strings, how to verify the result on the front end, and how to diagnose common issues.

This material is for site owners, editors, developers, and SEO specialists who need more than just enabling multilingual support. The goal is to get the site into a clean, publish-ready state: no mixed languages in menus, forms, notices, theme blocks, author profiles, or system messages. If you want a quick way to decide whether this add-on is worth testing on your project, start with the sections on real-world use cases, limitations, and result verification.

What Kinds of Strings This Tool Handles

In WordPress, some content is created explicitly by the user: a post, page, product, category, taxonomy term, or editor block. WPML translates those entities through its main translation management tools. But alongside them there is another layer: interface strings. These are short phrases that come from WordPress, a theme, a plugin, a widget, settings, or code. They may appear on the site, in an email, in a form, in the footer, in a user profile, or in a specific admin setting.

WPML String Translation is designed specifically for that layer. In the official WPML documentation, common examples include the site tagline, admin screen text, widget titles, menu labels, error messages, form instructions, and other phrases that are not posts or pages. In practice, that gives you a simple rule: if text is visible on the site but you cannot find it in the page editor, taxonomy editor, or a standard content translation screen, you should look for it as a string.

The main value of WPML String Translation is that it closes the gap between translated content and a truly multilingual site interface. Without it, you often end up with a page that is already translated into English while the form button is still in Russian, the subscription message still comes from the theme's default language, and the footer label is pulled from template settings instead of being translated with the page.

Where strings most often appear

It is easier to think of strings not as a technical table, but as the places where users interact with the site's interface. On a typical business site, that includes the header, footer, menu, contact form, subscription blocks, service cards, post-submit notices, cookie notice, author labels, search errors, and empty states. For an online store, you can add the cart, checkout, emails, attributes, shipping notices, and payment module text.

WPML can detect some of this text automatically when an administrator opens a translated page. Some strings need to be sent for translation through WPML -> Translation Dashboard, in the Other texts (Strings) section. Others have to be registered manually through utilities because the theme or plugin stores the text in settings, custom fields, profiles, or JavaScript files.

What not to expect from String Translation

It is important not to confuse responsibilities. This add-on does not replace translation for pages, posts, products, categories, and other content entities. It complements core WPML when you need to translate site structure elements and surrounding interface text. If your "Services" page itself is not translated, you should start with the normal page translation workflow, not String Translation. But if the page is translated and the form on it still says Submit, Required field, or Thank you in the wrong language, that is a string translation issue.

Practical check: open a translated page as a regular visitor and write down every phrase that is not part of the page's main content. If you cannot fix those phrases in the content editor, look for them through WPML String Translation.

Who WPML String Translation Is For, and When It May Be Unnecessary

This plugin is especially useful on sites where multilingual support needs to feel cohesive. That is not limited to large international projects. Even a small service site can lose credibility if a visitor switches languages and sees a mix of Russian, English, and system phrases. To an editor, that may look minor. To a user, it is a sign that the localization was never fully finished.

WPML String Translation is a good fit for sites running WPML Multilingual CMS or WPML Multilingual Agency where core WPML is already in use and strings outside the main content need to be translated. You should consider this add-on if the project uses an active theme with settings, a form, a slider, a builder, WooCommerce blocks, custom post types, widgets, author profiles, or integrations that output their own labels.

When you almost certainly need it

• The site has a form whose field labels, error messages, or success text come from plugin settings.
• The theme stores the footer, copyright text, contact block, tagline, or system phrases in its own settings panel.
• You use WooCommerce, and some emails, notices, cart strings, or checkout blocks appear in the wrong language.
• The site shows author profiles, biographies, job titles, or custom fields on the front end.
• After translating pages, there are still untranslated menus, widget titles, buttons, hints, and system messages.
• The site runs in multiple languages and needs to pass SEO review, where not only the text matters, but also clean URLs, the language switcher, and a consistent user experience.

When you may not need to complicate the project

If the site is effectively single-language and you only need to adjust theme translations in that one language, Loco Translate or standard localization files may be enough. If the site is not using WPML and you are not planning a full multilingual setup, installing String Translation separately makes no sense: it is an add-on inside the WPML ecosystem, not a standalone PO/MO editor.

The tool can also be excessive on a simple landing page where every phrase lives inside a single page builder and nothing is output from theme or plugin settings. In that case, most of the work happens through page translation, and strings appear only occasionally. In practice, though, almost any real WordPress site eventually gets a form, cookie banner, SEO plugin, widget, theme block, or integration that creates separate strings.

Team roles and access rights

String Translation is not only useful for developers. A content editor can find strings through filters and send them for translation, a translator can work with specific phrases, and a developer only needs to step in when a string is not registered automatically or a safe fix is required through an official hook. A solid workflow looks like this: the editor identifies the untranslated text and the page where it appears, the translator checks the strings table, and the developer gets involved only for theme settings, JavaScript, user meta, caching, or multi-server cases.

What to Check Before Installation and First Launch

Before installing it, do not jump straight into the strings table. WPML has system requirements, and String Translation runs on top of the core WPML infrastructure. If WordPress memory, PHP settings, the REST API, or write permissions are already problematic, the symptoms may look like "strings are not found," "translation is not applied," or "the table freezes," even though the root cause is lower in the stack.

The official WPML requirements page specifically highlights WordPress memory. A limit below the recommended level can lead to failures, menu sync issues, and incomplete translations. With String Translation, this becomes especially noticeable on sites with many plugins, a theme with lots of options, WooCommerce, and multiple languages. Scanning a theme or plugin can pull in a large number of strings, so weak hosting will hit its limits faster.

Technical preflight checklist

• Make sure core WPML is installed, activated, and configured: the default language is selected, secondary languages are added, and the URL format is set.
• Confirm that the add-on is actually installed: the admin area should show either WPML -> String Translation or the corresponding strings section inside Translation Dashboard.
• Open Tools -> Site Health and review warnings related to PHP, the REST API, memory, loopback requests, and filesystem permissions.
• Make sure the site is not running two multilingual systems at the same time. WPML, Polylang, TranslatePress, and similar tools should not be active in parallel on the same content set.
• Create a database backup before bulk-scanning themes, plugins, or importing strings.
• Clear existing critical errors in the site console and PHP logs before enabling String Translation.

Why it is better to start with a small set of pages

On a large site, do not scan everything at once. Start with one public-facing page that shows different kinds of strings: menu, footer, form, theme block, widget, and post-submit message. That gives you a clear view of which strings WPML detects automatically and which ones require manual registration. It also saves time: instead of working through a huge table with hundreds of phrases, you work through a specific user path.

The best first test is a page where the user can take an action. For example, a contact page with a form, a service page with a button, a product page with a cart, or an author profile. On pages like these, problems with labels, notices, custom fields, and dynamic elements become visible much faster.

What depends on the theme, plugins, and cache

Strings can be stored in different ways. A well-built theme uses translatable WordPress functions and the correct text domain. A form plugin may store labels in settings. A builder may save blocks in a template or in a custom post type. Some modern blocks may output strings through JavaScript. A page cache or object cache may temporarily show an old translation even after you save a string.

That means preparation is not just about installation. You need to know exactly where the problematic phrase appears, which component generates it, and whether the site is cached. If you cannot answer those three questions, troubleshooting turns into guesswork.

Installing the Add-On and Running the First Admin Check

WPML String Translation is installed as a WPML component. The official method is to use OTGS Installer or download it from your WPML account. After installation, the admin area should give you access to strings. In older guides, users often look for a separate WPML -> String Translation table, but in the current workflow, Translation Dashboard and the Other texts (Strings) section play a major role.

There is no need to describe installation as a separate purchasing or license registration process. In a practical guide, it is more useful to explain what should be visible after installation and how to confirm quickly that the add-on is working. If you can see the WPML menu, open language settings, and find the strings block in the translation dashboard, the basic setup is ready for testing.

Safe installation sequence

1. Back up the database and files, especially if the site is already live and receiving traffic.
2. Install core WPML and complete the basic language setup if that has not been done yet.
3. Install and activate WPML String Translation through the official WPML mechanism.
4. Open WPML -> Languages and verify that the languages and URL format are configured correctly.
5. Open WPML -> Translation Dashboard and locate the Other texts (Strings) section.
6. Open a test page in a secondary language while logged in as an administrator so WPML can detect untranslated strings.

First test with a string that is easy to verify

Do not start with a rare error notice. Pick a phrase that is easy to see on the page and easy to identify: a widget title, the site tagline, a form button, or a short footer label. In Translation Dashboard, scroll to Other texts (Strings), use search or filters, send the string for translation, and save it manually or through your chosen translation workflow.

After saving, open the public page in incognito mode or in another browser, switch the language, and check that exact location. If the site uses page caching, clear it after saving. If the result is visible only to administrators or not visible at all, move to diagnosis: the string may be coming from cache, registered in the wrong source language, or stored as something other than a standard string.

Quick checkpoint after installation

After the first test, you should have three confirmations: the add-on is active, at least one string has been found, and the translation of that string is visible on the public site. If any of those three is missing, do not move on to bulk scanning. Finish troubleshooting one string first. That is much faster than creating dozens of translations and only later realizing the real issue was caching, the wrong source language, or a theme setting.

Post-Install Workflow: From Page to String and Back Again

The most common beginner mistake is searching for strings in an abstract table without tying them to a specific place on the site. The right workflow runs in reverse: open the page first, identify the problem, understand the source, and only then search for the string. That is how WPML String Translation becomes a quality-control tool for a multilingual interface rather than a chaotic list of phrases.

The official documentation notes that WPML automatically detects untranslated strings when an administrator views translated content. You can also enable detection for all visitors, but that setting should be used carefully: on a busy site, it creates extra work and may collect unnecessary strings. For a normal rollout, it is enough to walk through the key pages as an administrator.

Step 1. Build a list of pages to review

Create a short list of URLs that contain interface strings. For a business site, that might be the home page, contact page, one service page, a blog post, an author page, and the search page. For a store, add a product page, cart, checkout, account page, and order email if you are reviewing email strings. Do not try to cover the entire site at once. Start with the pages that expose the widest variety of interface elements.

Step 2. Open the page in a secondary language

Log in to WordPress as an administrator, switch the front end to a secondary language, and open the page where the problematic string appears. This is not just a visual check. It may help WPML detect phrases that were not previously added to the strings list. That is especially relevant for theme and plugin strings that load only on a specific page.

Step 3. Find the string in Other texts (Strings)

Go back to WPML -> Translation Dashboard and open the Other texts (Strings) section. Search by the exact string fragment, domain, translation status, or language. If the phrase is short and appears many times, search using a rarer neighboring word. If the string contains variables or placeholders, do not remove them in translation. They often look like %s, {count}, {{name}}, or similar tokens.

Step 4. Send the string for translation or translate it manually

Depending on your WPML settings, you may translate the string yourself, send it to a translator, or use automatic translation. For short interface phrases, manual review matters more than usual. Machine translation may be grammatically correct and still not fit the site's interface style. For example, the same button may need to read "Submit," "Request a Quote," or "Get a Consultation" depending on the context.

Do not translate a string in isolation from the page where it appears. Short phrases often have no context. The word Apply might mean "Apply," "Submit an Application," or "Use Filter." Before saving, open the page and check what action that element is meant to perform.

Step 5. Verify the front end and clear cache

After saving the translation, open the page in the target language as a regular visitor. If the site uses a caching plugin, clear the page cache. If a CDN is in place, check whether it is still serving an older HTML version. If the string appears inside a WooCommerce block, builder element, or form, perform the actual action: submit a test form, add a product to the cart, open the notice, or trigger a validation error.

Quick takeaway: a string is not truly translated until you verify it in the exact place where the user sees it. An entry in the WPML table alone does not prove that the visitor will see the correct text.

Configuring Theme, Plugin, and Admin Strings

The most difficult cases begin where the string is not a standard gettext string from code. A theme may store the copyright text in its settings panel. A form plugin may keep a notice in a database option. A widget may have its own title. WordPress may store the date format, site tagline, or parts of custom settings in options. In cases like these, WPML does not always show the string automatically, and you need to register it as admin text.

For this scenario, the official WPML documentation recommends going to WPML -> String Translation, opening Utilities, expanding Not seeing strings you are looking for?, and then going to Admin Texts Translation. There, you can select the relevant options and add them to String Translation. After that, those strings become available for translation in the normal way.

How to tell when text is stored in settings

There are a few clear signals. You can change the phrase in the theme or plugin settings, but you cannot find it in the page editor. The phrase appears on many pages at once, such as the footer, a banner, the header button text, a phone number, or a form label. The phrase disappears if you deactivate a specific plugin or switch themes. And it is still missing from the strings table even after you visit the page in a secondary language.

In that case, do not blindly scan the entire site. First identify the component: theme, form, builder, SEO plugin, cookie plugin, widget, or WooCommerce add-on. Then, in Admin Texts Translation, look for the option group associated with that component. Option names are not always human-readable, so it helps to compare what you see in the settings, what is stored in the database, and what is rendered on the page.

When to scan a theme or plugin

Scanning a theme or plugin through WPML -> Theme and plugin localization is useful when the component contains gettext strings in its code, but the existing translations are outdated or not being loaded. The WPML documentation notes that auto-registration is designed to optimize performance and primarily exposes untranslated text. Scanning, by contrast, loads all strings from the component, including those that already have translations.

It is a powerful tool, but not a universal "fix everything" button. If the problem is in a setting, scanning the theme code may not find a value stored in options. If the problem is in JavaScript, you need JavaScript string detection. If the problem is cache, scanning again only increases the number of strings and will not change the public page.

How to work with source language and text domain

With themes and plugins, there is an important nuance: the source language of the strings may not be English. In that case, WPML may show the string as if it came from a different language, and the translator ends up working from the wrong source. For individual strings, you can select them in WPML -> String Translation and use the dropdown action Change the language of selected strings. For all strings in a specific text domain, use the Utilities section and the Set the original language of themes and plugins setting.

You should fix the source language before starting bulk translation. If you translate hundreds of strings first and only later realize they were registered under the wrong source language, you will have to review the results and possibly the translation statuses as well. On a small site, that is frustrating. On a multilingual store, it becomes an expensive mistake.

Practical decision map

JavaScript Strings, WooCommerce Blocks, and Dynamic Elements

Modern WordPress increasingly renders interface elements not only through PHP templates, but also through JavaScript. You can see this in the block editor, some forms, popups, WooCommerce blocks, interactive filters, calculators, and custom widgets. The user sees a phrase on the page, but it may not be a standard gettext string that is easy to find in the table.

The WPML String Translation changelog specifically mentions support for strings found in JavaScript files, along with the related option in the "Can't find strings" section. The official documentation outlines a working process: enable JavaScript string detection, open the necessary page, let WPML register the phrases, translate them, and then disable the mode if you no longer need it.

When to suspect a JavaScript string

You should suspect JavaScript if the text appears only after a user action: expanding a filter, selecting an option, clicking a button, leaving a required field empty, adding a product to the cart, opening a modal, or triggering a dynamic notice. Another clue is that the phrase is not visible in the original HTML when the page first loads, but appears later.

For WooCommerce, this is especially important in checkout blocks, cart interactions, and dynamic notices. Not every checkout string belongs to String Translation: some come from WooCommerce, some from WPML Multilingual & Multicurrency for WooCommerce, some from the theme, and some from payment or shipping add-ons. But if a phrase does not appear through the usual workflow and only shows up dynamically, JavaScript detection becomes the logical next step.

How to enable the mode without adding unnecessary load

1. Open WPML -> String Translation and find the Can't find strings block or the equivalent utilities section.
2. Enable detection for strings from JavaScript files only during diagnosis.
3. Open the page where the dynamic text appears in a secondary language.
4. Perform the action that triggers the phrase: submit the form, trigger a field error, choose a shipping method, or open the filter.
5. Go back to the strings table, find the registered phrases, and translate them.
6. After verification, disable the detection mode if continuous monitoring is not needed.

Do not leave special diagnostic modes enabled just in case. On a production site, balance matters: WPML should detect the strings you need, but it should not keep collecting unnecessary data or adding ongoing overhead after the diagnosis is complete.

How to verify dynamic strings

A normal page refresh is not enough. You need to repeat the action that generates the text. For a form, submit an empty field and check the validation error. For checkout, run a test scenario without real payment if your testing environment allows it. For a popup, open it in the target language. For a filter, select a parameter and check the empty state or the "products found" message.

If a string is visible only after an action, verify the translation only after that action. Otherwise, you are only confirming that the page loads, not that the translation works.

User Profiles, Authors, and Non-Standard Fields

One of the stronger sides of WPML String Translation is its handling of user meta. This includes profile data such as a user's name, nickname, biography, custom fields, and other information that a theme or plugin may display on the front end. On blogs, educational sites, expert directories, and service sites, this information is often visible to visitors but is not translated together with an ordinary page.

The WPML documentation describes two scenarios. For standard user information, you can open WPML -> String Translation, expand the section for missing strings, and go to Translate User properties. There, you choose the user roles whose properties should become translatable. After applying the change, you can filter strings by the Authors domain and translate them in the usual way.

Example: author job title on a team page

Imagine an agency website. Each author has a name, biography, and an extra field called "Job Title" that appears on the team card. The service pages are already translated, but the author card on the English version of the site still shows the Russian job title. If that field is stored in user meta, translating the page will not help: you need to make the field translatable and verify its output on the front end.

For standard properties, start with the WPML interface. For a custom user field, the official documentation provides the wpml_translatable_user_meta_fields filter. Code like this is best added through a child theme or a safe snippets plugin, not by editing the main theme files.

add_filter( 'wpml_translatable_user_meta_fields', function( $fields ) {
    // Slug of the custom field that should be translated through WPML String Translation.
    $fields[] = 'position';

    return $fields;
} );

After adding the field, confirm that it appears in the strings table, translate the value, and open the author card in a secondary language. If the theme retrieves the data through get_user_meta() or get_userdata(), WPML also documents the wpml_translate_get_user_meta filter, which allows it to return the translated value. Use it only if the front end continues to show the original text without it.

add_filter( 'wpml_translate_get_user_meta', '__return_true' );

Rollback is simple: remove the snippet, clear cache, and check the original output again. But before that, document which field you tested and on which page. In user profiles, it is easy to confuse a translation issue with a template issue where the wrong field is being rendered or an old value is being cached.

Practical Scenario: Cleaning Up a Contact Page Translation

Let us walk through a real task that comes up all the time. A bilingual service site has a translated contact page, but on the secondary language version, the form title, submit button, error message, success message, footer label, and one menu item are still untranslated. The goal is to make sure the visitor sees one consistent language across the entire page while the editor understands exactly where those strings live.

Goal

Get a fully verified contact page: translated main content, menu, form, form messages, footer, and post-submit result. You also need to confirm that after clearing cache, a regular visitor sees the same strings as the administrator.

Preparation

• Core WPML is configured, a secondary language is added, and the contact page is translated.
• WPML String Translation is installed and available in the admin area.
• You know which plugin renders the form and where the footer is configured in the theme.
• You have a test browser or incognito mode available for visitor-side checks.
• The page cache can be cleared after translations are saved.

Steps

1. Open the contact page in the secondary language while logged in as an administrator.
2. Write down the problematic phrases by group: menu, form, form messages, and footer.
3. Open WPML -> Translation Dashboard, go to the Other texts (Strings) section, and search for the first form text using an exact fragment.
4. If the string is found, send it for translation or translate it manually. Save it, then repeat for the button and the success message.
5. If the form string is not found, reopen the page in the secondary language and trigger the relevant form state: submit an empty form for the error or a valid test form for the success message.
6. If the text still does not appear, check Admin Texts Translation, because the form plugin may have stored the message in settings.
7. For the footer label, check the theme settings. If the phrase is stored there, add the corresponding admin text string to String Translation.
8. For the menu item, verify whether it belongs to normal menu translation or to strings. If it is part of a classic menu, use WPML menu translation rather than String Translation.
9. Clear the page cache and open the result in incognito mode.

Verification

On the contact page, four layers should now align: menu, main content, form, and footer. Then test the action itself: submit the form once with an error and once with valid test data. If the normal page load shows the correct language but the form error still appears in the source language, the issue is almost certainly a dynamic string, a form setting, or JavaScript.

A nuance people often miss

A form may use different text for different states: field label, placeholder, button text, required field error, email error, success message, anti-spam notice, email subject, and email body. Translating the button does not mean the whole form is translated. That is why you should test not only the appearance before submission, but the full interaction flow.

Quick takeaway from this scenario: on a contact page, you are not translating the "form" as one object, but a set of strings that appear at different stages of the interaction.

Verifying Results: Site, SEO, and User Experience

After translating strings, do not check only the visible text. A multilingual site works as a system: URLs, the language switcher, menus, cache, SEO plugins, the sitemap, WooCommerce, emails, and dynamic blocks all need to guide the visitor into the correct language version. WPML String Translation covers the strings, but the final result depends on the entire WPML configuration.

Front-end review

Open the site as a regular visitor. Walk through the key pages in the secondary language and look not only at the major headings, but also at the smaller elements: buttons, hints, empty states, filters, errors, the footer, pop-up notices, cookie text, and search UI. At every step, ask yourself: "Is this text coming from content or from site structure?" If it comes from site structure, it should be found or registered through String Translation.

Checking URLs and slugs

Some SEO settings are not tied directly to String Translation, but to core WPML settings. The WPML documentation covers translation of URL slugs for pages, posts, and custom post types. If the user sees a translated page but the URL still contains the original slug, that is not always a String Translation issue. Check WPML -> Settings, the settings for translatable post types, and the Page URL options.

For custom post type slugs, WPML allows you to define the translated slug in the post type settings. This matters for directories, portfolios, case studies, job boards, and other projects where the URL is part of a clear information path. But do not mix the tasks: a button label like Read more is translated through String Translation, while a post type slug is configured elsewhere in WPML.

Checking the language switcher

The language switcher is configured in WPML -> Languages. There you can control language order, flag display, the native language name, the language name in the current language, and colors. If the switcher itself shows the wrong label, check the WPML Languages settings first, not the strings table. If the theme adds its own heading or label around the switcher, that part may indeed be a theme string.

Checking cache and user roles

Do not test the site only as an administrator. An administrator may see fresh data, while a regular visitor sees a cached page. A translator may see only assigned jobs. A store customer may receive an email in the order language, while the admin notice arrives in another language. That is not always an error: different roles and scenarios may pull text from different sources.

Result verification should follow the real visitor journey. For a form, that means filling out the form. For a store, it means a test product and a test order in a safe environment. For an author profile, it means opening the public author card. For a menu, it means clicking the item and checking that the link leads to the correct language version.

Safe Enhancements and Technical Techniques

In most cases, no code is needed. WPML String Translation already provides interfaces for strings, admin texts, source language, user properties, theme or plugin scans, and JavaScript strings. But there are a few narrow cases where an official snippet or setting helps. The main rule is simple: do not edit WordPress core, WPML, the theme, or the plugin. Any change should be small, reversible, and based on an official hook or a documented constant-based mode.

Custom user meta through the official filter

If a public author card uses a custom field, add it to the translatable list through wpml_translatable_user_meta_fields. The earlier example with the position field works well for an author's job title. Put the code into a child theme or a snippets plugin, then verify that the field appears in the Authors domain.

Multiple servers and MO file synchronization

The official WPML documentation describes a rare but important case: the site runs on multiple servers, but String Translation stores MO files on only one of them. Requests that land on another server may show untranslated strings. For that situation, WPML provides a constant for wp-config.php:

define( 'WPML_ST_SYNC_TRANSLATION_FILES', true );

Use this only if the infrastructure is truly distributed and the symptom is confirmed: one request shows the translated string, the next one reverts to the original, cache has already been cleared, and the issue keeps repeating. The documentation warns that this mode adds extra logic and may affect performance. Rollback is simple: remove the line from wp-config.php, clear cache, and test the site again.

What you should avoid doing

• Do not edit strings directly in the database. It is too easy to break serialized data or lose the connection to WPML.
• Do not modify the main theme or plugin files just to fix one phrase. The next update will overwrite your changes.
• Do not enable bulk detection for all visitors without a clear reason on a busy site.
• Do not scan every plugin if the issue clearly belongs to one component.
• Do not delete large groups of strings until you understand which component created them and where they are used.

Common Problems and How to Find the Cause

String troubleshooting is different from troubleshooting a normal page translation. A string may have a different source, a different language, a different cache layer, a different loading moment, and a different registration method. That is why it helps to work through a chain instead of just pressing every button you can find: symptom, source, registration, translation, cache, and front-end verification.

The string does not appear in the list

Symptom: you can see the phrase on the site, but searching in Other texts (Strings) returns nothing. Possible causes include the string not being loaded on that page yet, being stored in settings, being rendered through JavaScript, belonging to user meta, or coming from a component that needs scanning.

First, open the page in a secondary language as an administrator. Then repeat the action that displays the phrase. If the string is still missing, check Admin Texts Translation. If the phrase appears only after a click or form submission, check the JavaScript strings mode. If it is an author field, review user properties and user meta.

Rollback for experimental actions: if you enabled JavaScript string detection, disable it after verification. If you added an unnecessary admin text string, do not delete it in bulk right away. First make sure it is not being used somewhere else.

The translation is saved, but the site still shows the old phrase

Symptom: the WPML table contains the translation, but the public page still shows the source text. Common causes are page cache, object cache, CDN caching, the wrong string source, the wrong source language, or the fact that the front end is rendering a different string with the same visible text.

Clear the site cache and CDN cache, open the page in incognito mode, and verify the URL language and language switcher. Then find the string by domain and confirm that the translation is saved for the correct language. If the site contains several identical strings, check the context and text domain. Sometimes one Read more gets translated while the public page is rendering a different Read more from another theme or plugin.

Strings are registered with the wrong source language

Symptom: the translator sees the source text in the wrong language, or the string behaves as if it should be translated "from English" even though the theme was written in another language. The cause is an incorrect source language assigned to the string or text domain.

For a few strings, use Change the language of selected strings. For all strings in a specific domain, open Utilities and use Set the original language of themes and plugins. After making the change, fully test one string before starting bulk translation.

Scanning created too many strings

Symptom: the strings table becomes noisy, with hundreds of phrases that have nothing to do with the page you are trying to fix. The reason is that scanning a theme or plugin loads all strings from that component, including ones that are already translated or rarely used.

Use filters by domain, status, and text. Do not try to translate everything. Start with one specific page and one specific phrase. In the future, use auto-registration from page visits first, and keep scanning for cases where you need to refresh component translations or find strings that were never loaded.

The translation exists on one server but not another

Symptom: the issue is inconsistent: after refreshing the page, the string is translated on one request and not translated on the next. If the site runs on multiple servers and cache has already been cleared, the issue may be MO file synchronization. The official WPML documentation describes the WPML_ST_SYNC_TRANSLATION_FILES mode, but recommends using it only when necessary.

First confirm the infrastructure: one server or several, shared storage or not, deployment method, and cache behavior. If the issue is truly tied to multiple servers, add the constant to wp-config.php, check the load impact, and verify the result. If the site runs on a single server, this mode is unnecessary.

A form or checkout string is only partially translated

Symptom: the button is translated, but the field error or success message is still in the source language. The cause is that different form states use different strings, and some of the text may be stored in settings or JavaScript.

Test the form as a sequence: initial view, empty-field error, email format error, successful submission, admin email, and user email. For checkout, add a test product, open the cart, fill in the required fields, and check the messages. Translating one visible button does not cover the entire flow.

How WPML String Translation Affects Site Performance and Maintenance

String Translation should not be treated as just a "lightweight phrase table." On a large site, it is a layer that interacts with the theme, plugins, translation files, cache, WPML tables, and the string detection process. The WPML String Translation changelog regularly includes fixes related to cache, scanning, WooCommerce emails, sitemap slugs, object cache, multisite, and performance. That is normal for a complex add-on, but it also means it needs to be introduced carefully.

To avoid unnecessary load, use a focused approach: translate strings based on real pages, do not leave diagnostic modes enabled without a reason, do not scan everything blindly, clear cache after meaningful changes, and record which component generates the problematic string. This makes maintenance much easier. If a phrase disappears again a month later, you will know exactly where to look.

Maintenance routine after updates

After updating WPML, the theme, WooCommerce, or a form plugin, run a short control pass. Open the pages where strings mattered before: contact page, cart, checkout, footer, author profile, and search. Check whether any new untranslated phrases have appeared. If a theme or plugin update introduced new strings, they may need registration or translation.

When to bring in a developer

An editor can usually handle finding and translating standard strings. A developer is needed when a string does not register, lives in custom user meta, comes from non-standard code, depends on multiple servers, breaks after caching, or requires wpml-config.xml for compatibility. In those cases, it does not help to ask the translator to "try again." You need to identify the data source and the registration method.

How not to break the editorial workflow

Agree on some rules. The editor does not delete strings in bulk. The translator does not modify placeholders. The developer does not edit core files. The administrator clears cache after string changes. Any disputed phrase gets checked on the public page. If the site is large, keep a table with columns such as page, source phrase, source component, domain, language, status, and who verified it. It may sound tedious, but it saves hours during a multilingual site release.

When WPML String Translation Is Worth Using

WPML String Translation is a strong choice if you already use WPML and want to bring a multilingual site up to a professional standard: not just translated pages, but also buttons, forms, the footer, widgets, notices, author profiles, theme strings, plugin settings, and dynamic elements. It is not the simplest layer of WPML, but it is often the part that separates "the content is translated" from "the site is truly ready for visitors in another language."

Before rolling it out, check the core WPML requirements, create a backup, choose one test page, and fully work through a few strings. After that, you can expand to admin texts, JavaScript strings, source language, user meta, scanning of specific components, and regular post-update checks. That sequence is far more reliable than bulk-scanning and translating everything that happens to appear in the table.

If, after reading this, you already know which strings you need to review on your own site, move on to a test installation and safe verification. Closer to the download block, you can download the latest version of WPML String Translation, install the add-on into your WPML setup, and run the first scenario on a single page before making it part of your full editorial workflow.

The final check is simple: the visitor switches languages, follows a real user path, and never runs into a random phrase from another language. If that holds true on your key pages, WPML String Translation has done its job.