Formidable Forms Polylang Multilingual - WordPress Plugin

How to Configure Formidable Forms Polylang Multilingual for Multilingual WordPress Forms

This detailed guide explains how to prepare, translate, test, and maintain a multilingual Formidable Forms form with Polylang.

Formidable Forms Polylang Multilingual is useful when a WordPress site needs an entire form to work correctly on language-specific pages: translated fields, choice options, post-submission messages, and email notifications for the team. For reliable behavior, keep the page language, visible form text, and post-submission action separate. Polylang manages languages and pages, the Formidable add-on helps translate the form, and Formidable Forms stores the entry and triggers the appropriate action.

What the Formidable Forms and Polylang Integration Solves

A translated page loses credibility when a visitor reaches the form and sees source-language labels, an error in another language, or an unclear thank-you message. Once the add-on is enabled, the Translate Form command becomes available in the form settings. It lets you translate labels, descriptions, and options, then publish the form on language-specific pages created with Polylang.

Email notifications and confirmations should be designed separately. Formidable documentation recommends using separate actions for different languages with conditional logic. This lets you send one clear email and show one matching message instead of triggering several actions at once.

When This Setup Makes Sense

This setup works well for a service website receiving inquiries from different regions, an educational project with registration forms, a catalog that accepts consultation requests, a community using questionnaires, or a corporate site where staff respond in several languages. It is especially useful when the form contains selectable options, consent fields, email routing, or publicly displayed saved entries.

Three Layers of a Single Submission

The first layer is the language-specific page. The second is the text the visitor reads: headings, labels, options, and the button. The third is the saved entry, email, message, or redirect after submission. The add-on helps with the second layer, but the rules for the third layer must be created and tested separately. This explains why a form may look translated while the email still arrives in the wrong language.

Scope Boundary: Translating the Interface Is Not the Same as Creating New Business Rules

It helps to agree in advance on what counts as a multilingual form for a particular project. In the basic setup, the same visitor journey exists in several languages: the person provides the same information, selects the same inquiry category, and receives a response in the language of the page. The wording, hints, button text, consent explanation, and follow-up confirmation change. The meaning of the field, its saved key, the recipient of the inquiry, and the rule that routes it to the correct queue should not change on their own.

A different situation arises when a language version is needed for more than translation. For example, a company may accept consultation requests in one region but ask visitors in another region to choose a partner first; one language version may collect consent for a callback while another requires a different contact process. That is a separate design decision. Do not try to hide such a difference in a few random translations or in one overly complex condition. First describe the difference in the intended workflow, then decide whether one shared form with additional fields and rules is still appropriate or whether separate forms are needed. The add-on is convenient for localizing a shared structure, but it does not eliminate the need to clearly design different processes.

Before you begin, create a small language map. For each language, note the page URL, the clear language name, the expected Polylang code, confirmation text, a thank-you page if needed, and the recipient for test emails. Also list fields that must not be translated technically: separate option values, internal keys, addresses, and shortcodes. This map takes only a few minutes to create, but it prevents you from replacing a working code with a polished phrase during translation and then having to trace incorrect routing later.

Pay particular attention to the language switcher. A visitor may open a form in one language, switch to another language-specific page, go back, or submit the form from a tab that was opened before the cache was cleared. Do not promise that entered data will persist across those actions unless that behavior has been tested on the actual site. Instead, define the expected behavior: which page the visitor completes the form on, which language should be stored in the hidden field, and what the team should see in the entry. Then reproduce that path manually. Testing the switcher is part of testing the visitor journey, not just the translation quality.

This approach helps keep component roles separate. Polylang handles language and relationships between WordPress language versions. Formidable Forms handles fields, entries, and actions. The Formidable add-on connects the translated form interface with the Polylang context. An email service, cache, theme, and other plugins may affect the final experience, but they should not be blamed without a separate check. When roles are separated, the team can identify where to look for a setting and how to safely restore a working state more quickly.

Submission Architecture: What Visitors See and What the Form Stores

A reliable submission follows a short chain: the visitor opens a language-specific page, Polylang establishes the locale, Formidable displays translated elements, an entry is created, and a condition selects one email and one confirmation. Define the expected outcome for every link in this chain in advance. Then a test submission will show exactly where a mismatch appears.

Visible Labels and Saved Values

For Dropdown, Radio Buttons, and Checkboxes, use separate saved values that differ from the visible labels. A visitor may select "Consultation" in one language or another, while the email condition compares the stable value consultation. This value does not change because of translation and remains clear in entries, exports, and filters.

• Field and purpose: The inquiry topic determines the notification route.
• Visible text: The visitor reads a localized label.
• Saved value: The rule uses a short identifier that is not translated.
• Verification: A test submission shows the label, code, and action outcome.

Practical rule: lock down the structure and saved values first, then translate the labels. Otherwise, a form that looks identical may conceal different post-submission conditions.

Hidden Language Field

To select the correct email and confirmation, add a hidden field with the shortcode [get_current_language]. The official Formidable example retrieves the Polylang language code and stores it with the submission.

add_shortcode( 'get_current_language', 'polylang_get_lang' );
function polylang_get_lang() {
    return pll_current_language( 'slug' );
}

Place the snippet in a child theme or a snippets manager, not in core files. On a copy of the site, submit the form from every language-specific page and check the hidden field value in Entries. To roll back, disable the snippet and remove the shortcode from the field's default value.

Define the Data Before Designing the Form

A stable setup starts with a simple description of every field. Specify who enters the value, what it means, whether it should be shown to the visitor after submission, whether it should be sent to a staff member, and whether it participates in a condition. For a name and message, clear presentation is usually important. For an inquiry topic, both the label and an independent code matter. For the hidden language field, the saved code matters most because visitors should not edit that technical attribute. This description helps separate submission data from interface text before you even open the translation screen.

Do not confuse a human-friendly name with an identifier used by rules. An operator may see "Technical Support" in an email, but the condition does not need to compare those words. If an editor changes the label to "Help with an Existing Order" a month later, the route will not change as long as the internal value remains support. This makes the form resilient not only to translation but also to ordinary text editing.

Entry Lifecycle and Checkpoints

Every test submission has several observable states. First, the form must appear on the correct language-specific page. After submission, Formidable creates an entry with entered and hidden values. Next, the action whose condition matches that entry is triggered. Finally, the visitor sees a message or follows a URL, and the team receives an email. Capture one reference example for each language: save the page address, selected option, language code, on-page outcome, and received email. This is not bureaucracy; it is a way to distinguish a display issue from a data or action issue.

If an entry does not contain the expected ru or en value, do not start by rebuilding the emails. Conditional actions work with what was already saved. Return to the hidden field, shortcode, and page from which the test was submitted. If the code is correct but no email arrives, you now have a narrow area to inspect: the specific action, its condition, recipient, and subsequent delivery. If the email is correct but the visitor sees the wrong text, check the confirmation or redirect separately. This sequence prevents chaotic changes to every setting at once.

Name actions so they can be understood without opening every condition: for example, "Email - ru - support" and "Confirmation - en." The name does not affect behavior, but it makes form audits noticeably easier. Once there are several forms, a consistent naming pattern quickly reveals a missing language or a suspicious copy of an action. If several inquiry topics are used, you can add the stable category code to the name. Try not to use only visible translated phrases: they are easy for a reader to understand, but less useful for technical verification.

Changing a Form Without Losing Control

After publication, do not edit the translation, separate values, and conditions at the same time. Break the change into small steps. If only a label changes, save the translation first, then check the form in one language. If you add a new topic option, first define its saved code in the source structure, then add localized labels, and only then create or expand an action. If a route changes, do not overwrite the old rule without testing: record the current outcome, make one change, and submit an entry with a precisely known set of values.

For important forms, keep a short verification card alongside the site documentation. It only needs the language-page URLs, the form ID or clear name, hidden field names, permitted codes, the action list, and the date of the last test submission. Do not include visitor personal data in this card. Its purpose is to let another administrator repeat the check after an update, site migration, or translation change without having to reconstruct the form from memory.

Prepare WordPress Before Enabling the Add-On

The official sequence starts with an active Polylang installation, then requires a current premium version of Formidable Forms, after which the add-on is enabled through Formidable → Add-Ons. Availability depends on the Formidable plan, so check the admin area before you design the translation.

1. Check the language of each page and the relationship between language versions in Polylang.
2. Open the source form and make sure it displays without errors.
3. Identify fields with options, calculations, conditions, and notifications.
4. Prepare translations for labels, messages, options, and email subjects.
5. Create a separate test address for verification notifications.

If the form page is cached, an old version may still appear after saving. Clear the cache using the current solution, open the language-specific URL in a private window, and repeat the same test. Do not exclude the form from caching without a reproducible symptom.

Check the Source Form Before Localization

Before enabling the add-on, submit the source form as an ordinary visitor. Check required fields, email formatting, available options, the entry in Entries, and the post-submission action. If the base form already fails to create an entry or send a notification, translation will only make diagnosis harder. Restore a predictable single-language path first, then add the language layer. This also gives you a baseline: after configuring Polylang, you can compare not only the text but also the original behavior.

Confirm that the page uses the intended form rather than an outdated copy, saved block, or another shortcode. On large sites, similar forms often differ by only one recipient address or consent option. Open the page in the editor and match the published form with its name in Formidable. Then enter a noticeable but non-personal marker in a test field, submit the form, and find it in the entry list. This simple test confirms the connection between the page and the specific form more reliably than comparing names.

Prepare a Safe Launch Process

If the form receives real inquiries, choose a time when changes can be checked in sequence. You do not necessarily need to disable the form for visitors, but avoid changing translations, emails, and pages for the first time when the team cannot notice incorrect routing. Prepare a test email address, a clear marker for test submissions, and access to the entry list. If a staging copy is available, first test add-on activation, the hidden field, and conditional actions there, then repeat the same minimum process on the live site.

Define the rollback in advance. For a translation, that may mean returning to previously saved text. For a new action, it may mean temporarily disabling only that action until the condition is understood. For a visitor-facing page, it may mean restoring the correct Polylang relationship between language versions. Do not delete form entries or change several components in an attempt to "start over": that removes the information that shows where the failure occurred. A saved test entry with a language code often becomes the most useful evidence during review.

Consistent Requirements for Language Pages

Form translation works in the context of a page, so check both sides of every page pair. Each should have clear introductory text, an accessible language switcher, and the form placed at the same logical point. If one version says "Describe your request" while the English page leads to another form or contains an outdated link, Translate Form will not solve the problem. First fix page relationships and publication with Polylang, then compare the form output.

Do not add a new language by guesswork. Add it in Polylang, create the linked page, prepare string translations, and add an action rule only after the language code is known and verified. In a test submission, that code must reach the entry exactly as the condition uses it. This order becomes especially important with a third or later language: the number of email and confirmation combinations grows, and one missed setting may only become visible to a visitor.

How to Translate a Form Without Breaking Conditions

When you open Translate Form, move through the form in the visitor's order: heading, description, fields, options, hints, button, and message. Read selectable options particularly carefully. They look like simple text, but they often affect email routing, entry filtering, and data display.

If separate saved values are enabled, translate only the user-facing label. The value sales remains sales, even when the visitor sees a translated equivalent of "Sales." Do not translate field keys, identifiers, recipient addresses, condition codes, or verified shortcodes. These are technical links, not interface text.

1. Translate the heading, introductory text, and explanation of the form's purpose.
2. Translate labels and hints while preserving the meaning of required status and input format.
3. Translate selectable options and recheck their separate saved values.
4. Translate the button and visitor-facing messages if they are defined by the form.
5. Save the changes and check the form at the actual language-specific URL.

Consent Fields and Long Labels

Whether a field is required is set in the field configuration, not by its translation. After localization, read the form as a visitor: is the required action clear, does the appropriate language version of the policy open, and has a long label been cut off? Do not shorten legal meaning just to make the design look cleaner. First adjust width, wrapping, or placement through Formidable and the theme without changing the checkbox's technical value.

For consent, it is convenient to keep a neutral value such as consent_yes while showing localized text to the visitor. Use the stable marker in conditions and filters. You can show a readable label in the email if an operator needs it, but do not use it to determine whether consent was received.

Form Translation and Page Translation

Saving a form translation does not automatically create a language-specific page. Open the page containing the form, create its translation through Polylang, and make sure the form is published in an equivalent location. Different introductory paragraphs and links can live on language-specific pages, but the field structure should remain shared unless there is a confirmed reason to make it different.

Verify the outcome: every page shows translated text, options retain stable values, and a test entry appears in the admin area.

Inventory Strings Before Translation

Do not begin with the first field you happen to see. First open the form and identify every place where a visitor reads text or makes a decision: heading, description, labels, hints, options, button text, error explanation, consent, and confirmation text. Separately mark elements seen only by the team: action name, recipient address, technical code, and internal comment. Translate the first list and protect the second from accidental editing. As a result, the translator has a clear assignment and the administrator does not have to reconstruct a deleted condition afterward.

For selectable options, check not only individual words but also the meaning of the distinction. A pair such as "New Request" and "Question About an Existing Request" must remain distinguishable in every language, otherwise an operator may receive a technically completed but unclear inquiry. If an option affects routing, its visible wording should help the visitor make the correct choice while its technical value remains stable. Do not use overly broad labels such as "Other" without an explanatory field if the department genuinely needs to understand the nature of the inquiry.

Localization Order for a Complex Form

Start with a short visitor journey: open the language-specific page, read the form from top to bottom, and complete it once. Then translate it in blocks in the same order. After the heading and description, move to the fields, then options, then the button and messages. This approach is more than convenient. It shows whether a visitor has enough context before encountering a required field, category choice, or consent field. An editor may display a single string, but only the page reveals whether the connection between a hint and its field has been lost.

Check every group of fields at four levels. First, the text should be clear to a speaker of the language. Second, required status and input format should be explained as clearly as in the source form. Third, the value in the entry should be saved as expected. Fourth, if the field participates in a condition, it must select the right action. Do not limit the check to appearance. The most dangerous error looks neat: the label is translated, but the created entry contains an unexpected value or triggers the wrong email.

If the form uses conditional field display, test every available branch. For example, a visitor selects a category and then sees an additional question. Translate the option itself, the field that appears, and its hint. Then submit a test using every option that opens a hidden block. Do not change the stable saved option value. A translated conditional branch is only complete when the visitor understands the question, can complete it, and the entry saves data that the team can understand.

Text with Variables and Technical Fragments

Forms often contain shortcodes, inserted values, and technical tokens. Do not translate the code itself, but translate the surrounding sentence so the final text remains natural. Before saving, match opening and closing elements, brackets, and field names. If a translator encounters a construction whose meaning is unclear, it is better to leave a note for the administrator than to guess. A damaged shortcode may not be visible in the translation screen and may only surface in an entry, email, or public output.

The same rule applies to links inside consent text and references to language-specific pages. A visitor should reach the policy version that matches their language, but technical URLs should not be replaced with a creative translation. After publication, open the link on the page as an ordinary visitor. Check that it leads to an existing page, returns an understandable language version, and does not leave the visitor on a page with unrelated consent text.

Editing After Initial Publication

The first translation should rarely be treated as final immediately after it is saved. Open the page in standard and mobile views, read the form aloud, or ask a colleague to complete a test without prompts. It is especially helpful to observe how a person understands the options and required fields. If they hesitate, clarify the text first rather than adding new rules. When only a label changes, stable saved values and already tested actions remain functional.

After an editorial change, repeat at least one complete test in the affected language. Check the on-screen confirmation, entry, and email even if only one label was edited. This is a brief safeguard against accidentally changing a neighboring string or option. Keep the source of approved text for sensitive blocks in your documentation: consent, response-time statements, and instructions for sharing data. Then a translation can be updated deliberately instead of reconstructed from an old email or screenshot.

Configure Emails and Messages by Page Language

Translated labels do not guarantee a translated response after submission. Formidable documentation recommends a separate email action for each language with conditional logic. The same approach applies to a success message. A visitor on a Russian page receives a Russian confirmation, a visitor on an English page receives an English one, and only one set of rules runs in each case.

First add the hidden language field and verify that it saves the expected code. Then, in Settings → Actions & Notifications, create an email for one language, define the recipient, subject, text, and a condition where the hidden field equals that code. Repeat for the next language. Do not copy an action without checking the condition: two similar rules can easily retain the same code, causing one email not to arrive while another may be sent twice.

Conditions Without Fragile Comparisons

Conditions should be based on what the form actually saves. For language, that is ru or en from the hidden field. For inquiry topic, that is a separate value such as sales or support. If a notification depends on both attributes, the rule should require both to match. Do not compare visible text such as translated versions of "Sales": a translator may change that label without understanding the technical consequence.

Include only the information an operator needs to respond in the email subject and body. A good test email immediately shows the language, topic, and contact details without becoming a copy of the entire page. The simpler the template, the easier it is to spot an issue after an update or translation change.

Confirmation or Redirect

For a simple setup, a separate success message is enough. If visitors should be sent to a language-specific thank-you page, create separate redirect actions with the correct language-specific URLs and the same conditions. After saving, check not only the text but also the browser address. An incorrect relationship between language pages can return a visitor to the source locale even when the Formidable rule is correct.

Build an Action Matrix Before Creating Notifications

When language affects the email, it helps to write down all permitted combinations in a worksheet or working table first. In a simple form, there will be two rows: ru leads to a Russian email and Russian confirmation, while en leads to English versions. If there are three inquiry topics, the matrix may describe combinations of language and category. You do not need to create many actions immediately: first determine whether the recipient differs by topic or only the email wording changes. However, every existing combination must be unambiguous and testable.

The matrix does not replace Formidable settings, but it prevents you from accidentally creating two overlapping responses. For every test submission, you should be able to name one expected outcome in advance. If the outcome is unknown before the form is submitted, the rule is not described clearly enough. Fix that in the diagram first, then implement the rules as conditional actions.

Team Emails and Visitor Confirmations Serve Different Purposes

An internal notification should help a staff member begin working with an inquiry. It usually needs contact details, the message, a stable category code, and the language in which the request arrived. A human-readable category label is useful for reading, but the internal code makes it easier to verify which condition ran. If the email subject includes language or category, use a clear format agreed on by the team. Do not overload the subject with the entire form content: it is for quick sorting, while details can remain in the email body and entry.

A visitor confirmation has a different goal: it should show that the form was accepted, explain the next step, and avoid revealing unnecessary information. Write it briefly and specifically. If the team responds in a particular order, describe that carefully without promising response times the site cannot guarantee. When using a redirect, the language-specific thank-you page should continue the same conversation: its heading, next link, and contact path should be in the appropriate language. Do not use a redirect simply because it seems more sophisticated; a clear standard message is often more reliable for a simple request.

How to Test Conditional Logic Step by Step

Create one action for the first language and complete it fully: recipient, subject, text, and hidden-field condition. Submit a test from the corresponding page. The entry should contain the correct code, the inbox should receive one expected notification, and the browser should show the associated confirmation. Only then copy the structure for the second language and change the parts that genuinely need to differ. This prevents you from reproducing a broken condition in several places.

If the action also depends on the inquiry topic, first test the selected topic in both languages. Then add new topics one at a time. After every step, compare the entry and email. Do not create a condition based on how an option looks in a dropdown: use its configured saved value. If you need to change the option list, repeat the test for affected combinations because the old visible label may no longer describe the actual data in the entry.

Separate a Rule Problem from an Email Delivery Problem

A missing email does not always mean that Polylang or form translation is not working. First check whether an entry was created and which language code it contains. Then check which action should have run for those values. If the entry and rule are correct but the test notification cannot be found, investigate delivery to the test address separately using the methods accepted for the site. Do not replace rule verification with random changes to email text or page language.

Likewise, a duplicate should be broken down into facts. There may be two actions with conditions that both match, but there may also be two separate sends from another part of the form. Record the exact number of emails, their names or distinguishing template parts, and the values in the test entry. Then temporarily disable only the suspected duplicate and repeat one test. This limited rollback preserves a clear picture without interrupting the remaining verified paths.

Maintenance After Changing a Recipient or Text

Changing a recipient address may seem harmless, but it affects the final outcome just as much as translation does. After changing an address or email template, submit a test from every language that uses that action. If the team distributes inquiries manually, keep the language context and topic code in the email so an operator does not have to infer them from the spelling of the visitor's name. If a category changes organizationally, update the action matrix first, then the rules themselves, and only remove the outdated route after testing.

Follow the same order when editing a confirmation. Do not change the language URL, text, and condition in one action without an intermediate test. First make sure the condition selects the intended action, then test the text or address. This discipline is especially helpful during seasonal site updates, when pages, forms, and emails may all change at once. Clearly separating the steps makes it possible to quickly roll back to the last known working version.

Practical Example: A Two-Language Consultation Request Form

Imagine a form for a service website. It collects a name, email address, inquiry topic, and message. The goal is to show a clear confirmation to the visitor and send an email to the appropriate team. Visible text differs on the Russian and English pages, but the entry structure, saved values, and rules remain shared.

Prepare the Example

Create fields for name, email address, topic, and message, along with a hidden language field. For the topic, define visible options and the values sales, support, and partner. Prepare language-specific pages and form translations. In the test mailbox, create separate folders so you can see which language-specific action ran.

1. Enable the add-on and add [get_current_language] to the hidden field value.
2. Check separate values for the inquiry topic and do not change them in the translation window.
3. In Translate Form, complete the heading, labels, options, and button for the second language.
4. Create an email and confirmation for every language code with precise conditions.
5. Publish the form on the linked language-page pair and submit a test on each page.

Two Required Test Submissions

First open the Russian page, choose a topic, submit the form, and record the language of the text, hidden-field code, topic value, recipient, and confirmation. Then repeat the same process on the English page. In both entries, the technical topic value should be the same, while the visible text should match the page.

If department routing is needed, first test one topic in both languages, then add the next one. For example, a support inquiry on the Russian page should trigger a Russian support email, while the same inquiry on the English page should trigger an English one. Step-by-step testing reveals an incorrect condition faster than running every combination at once.

Example summary: one form structure stores stable data, Polylang provides language context, and Formidable conditions select a clear response for both the visitor and the team.

Detailed Configuration Process for the Example

First decide what a staff member must receive from any inquiry regardless of language: name, email address, selected category, and message text. These fields form the shared structure. Then define two technical attributes. The first is the language code from the hidden field. The second is the separate saved topic value. For demonstration, sales, support, and partner are enough. They do not need to be displayed to visitors in that form: the Russian page can show clear Russian choices, while the English page shows English ones.

Next, create the Russian page and its linked English page with Polylang. Place the form at the same logical point: after a short explanation but before secondary links. A visitor should understand why they are being asked for contact information before reaching the first field. Check that opening each page displays the correct form translation. If one page shows the correct page heading but source-language field text, do not move on to emails: complete the form translation and publication first.

Then configure just one path: the Russian page and sales. Complete the form using test data that is clearly distinguishable, such as a neutral marker in the message reading "ru sales test." After submission, record the URL, visible topic label, the sales value in the entry, ru in the hidden field, the confirmation shown, and the email received in a verification table. This sample becomes the reference. Then repeat it on the English page with the same topic code. Technical values should be comparable, while the interface, confirmation, and email language should differ as intended.

Move from One Route to the Full Matrix

Once the sales route works in both languages, add the support topic. Do not change all text, addresses, and conditions at the same time. First make sure the new option appears correctly in both translations and that its saved value reaches the entry. Then add or adjust the support actions. Submit two test inquiries: one Russian and one English. Only after that should you introduce the partner category. This order keeps each subsequent check short and avoids a situation where it is unclear which of six possible combinations is broken.

If categories need different recipients, test both the language and the address at the same time. If the recipient is the same but the team needs to know the reply language, make sure the notification includes the code and a clear language marker. Do not rely on the language of a free-form message: a visitor may write in English on a Russian page or the other way around. The page context stored in the hidden field describes the form route more accurately, while the message text remains the content of the request.

Handling Incomplete Entries and Visitor Errors

Testing should cover more than successful submission. Leave a required field empty, enter an invalid email address, choose different topics, and make sure the hints are clear in the current language. In this situation, the entry and email should not be the only proof of quality: the visitor must understand how to correct the error before submission. If one language has a long hint, check it in the real field layout, not just in the translation window.

After correcting the error, complete the form and check the entry again. This confirms that translation did not affect required status and that the condition ran only after an entry was actually created. Do not use colleagues' real personal data for testing unless necessary. Agreed test names, addresses, and message markers are enough, as long as they are easy to locate and distinguish from real inquiries.

Handing the Setup Over to Another Administrator

Once the example is complete, try to repeat it from a short instruction without randomly opening the translation editor. The instruction should contain the two page URLs, form name, hidden language field, allowed topic codes, action names, and testing order. If a colleague can submit two entries and explain why each email arrived through the correct route, the setup is maintainable. If only its original author remembers it from the interface, adding a third language or a new staff member will create unnecessary risk.

This setup can be adapted to registration, quote requests, or questionnaires without changing the principle. The fields and allowed categories change, but the chain remains the same: language-specific page, translated interface, stable values, saved context, and one testable action. Do not copy the example text mechanically. Preserve the design and verification method, then adapt wording and recipients to the site's actual operations.

Verify the Outcome After Publication

Verification starts not in the editor but along the path of an ordinary visitor. Open every language-specific URL in a private window, complete the form, submit it, then inspect the entry and test inbox. Only this complete chain proves that translation, saving, and the post-submission action work together.

• Page: The URL language and content match the selected locale.
• Form: All labels, options, and the button are clear in the current language.
• Entry: The hidden language and field values are saved as expected.
• Confirmation: One message is shown or one redirect takes place.
• Email: It reaches one recipient and contains the correct test data.

Save this checklist in the project documentation. After updating Formidable, Polylang, the theme, or the cache, repeat the same checks. A regression then becomes a specific difference in behavior rather than a vague visitor complaint.

Acceptance Test Matrix

For two languages and several categories, create a small set of required tests. At a minimum, verify a successful submission in every language and one path for each route. If the inquiry topic affects the recipient, test every permitted topic at least once. If the topic affects only the email text, still verify that this difference does not trigger a second action. You do not need to manually complete an endless number of combinations, but every condition should have at least one proven example.

Record the outcome as facts: page URL, selected option, language code in the entry, expected action name, confirmation text, and test recipient address. A note such as "everything seems to have arrived" does not help during the next review. It is better to keep a short table with a "passed" or "failed" result and a link to the test entry if project rules permit storing such links. Do not copy personal data into the log; use neutral test values.

Check the Public Page Under Real Conditions

The admin area shows settings, but it does not always show what a visitor sees. Open the language-specific URL in a private window after a clear cache reset, navigate to the form through the normal path, and pay attention to the language switcher, consent links, and display of long labels. If the form is embedded on a page using theme blocks, also check a narrow browser window. The goal is not to find decorative differences, but to ensure that required actions, choices, and the button remain clear and accessible.

If a private-window test differs from the administrator's view, do not draw a conclusion immediately. Record the URL, language, time, and visible text, then repeat the test after a clear cache-related action. Comparing those facts helps determine whether the browser is displaying an outdated page, an incorrect language relationship, or a genuinely incorrect form translation. Do not add another translation until you know which page version the browser is testing.

Separate Form Submission from Email Delivery

A successful on-screen message and a newly created entry prove that the visitor path reached Formidable. They do not always prove that an external inbox has already received the notification. Therefore, record both outcomes separately during acceptance testing. If the entry was created and the action selected correctly but the email is missing, do not change an option translation or the language code. Look for the issue in the next part of the chain using a safe check accepted by the project.

Conversely, an email without a clear confirmation does not mean the form is fully ready. For the visitor, the page after submission completes the process. Check that they see one outcome, that it is written in the expected language, and that it does not invite them to resubmit an inquiry that has already been accepted. When using a redirect, record the final URL in the log. This makes it easier to identify a situation where the email was correct but the thank-you page opened in another locale.

Repeat Verification After Changes

After updating Formidable, Polylang, the theme, or the caching mechanism, you do not need to check every form at random all day. Start with one reference form and one complete path in each language. If the form uses several routes, select those that include a hidden language field, separate values, and a conditional email because they contain more connection points. If you find a difference, compare the new test entry with the saved reference sample: language, values, action, confirmation, and email.

If a test fails, limit the change. Temporarily restore the last confirmed text or disable only the new action if that is safe for the site, then repeat one test. Do not delete entry history or replace all language-specific pages at once. The purpose of rollback is to restore a clear route, while the purpose of further diagnosis is to identify the exact cause rather than merely make the symptom disappear by chance.

Displaying Translated Values and Working with Views

If a form only sends an email, translating fields and actions is usually enough. It becomes more complex when an entry is displayed on the public side of the site through a view. Here, decide separately what is visitor-facing text and what is a technical value. If labels and options have already been translated in the form, they do not need to be translated again in the output.

For a value that truly needs localization when displayed, Formidable documentation provides the shortcode [translate_value value="[25]"] and a function using pll__(). Use this only after confirming that it is necessary. Do not apply translation to a saved sales value or another internal code if it is needed by a filter, integration, or route.

Check a view in two passes. First, make sure the entry is included in the query based on a stable value. Then open the public output on every language-specific page and evaluate the visible text. This order separates a data retrieval issue from a localization issue.

Importing and Exporting Translations

Formidable does not manage translations when forms are imported or exported. Translation strings must be moved through Polylang. Therefore, after a migration, do not assume the form is ready merely because its fields are present. Check Polylang strings, page relationships, the hidden language field, actions, and test emails in every language.

Separate Entry Selection from Its Presentation

Public entry output through a view is best designed as two independent steps. First, the form or view finds the required entries based on a stable attribute: for example, a technical topic code, a language-independent status, or another explicitly defined condition. Then it displays text that should be understandable to visitors on the current page. If these steps are mixed, it is hard to tell why an entry did not appear: it was not selected, or it was selected but displayed with the wrong text.

Separate saved values are particularly useful here. The value sales works for stable selection and does not require guessing which language was used to complete the form. When human-readable text is needed beside it, display it deliberately and check it on the language-specific page. Do not translate an internal code just for appearance. It may be used by a filter, integration, or internal report, and localizing that value would create different keys for the same concept.

When translate_value Is Needed

The documented shortcode [translate_value value="[25]"] applies when a saved value genuinely needs to be shown to visitors in localized form. Before using it, ask three questions. Is the value human-facing text rather than a technical code? Should it differ on different language-specific pages? Does a confirmed translation of this string exist in Polylang? If any answer is unclear, first test the standard output and do not add translation to the template.

The function using pll__() should be used exactly where the documented example expects it. Do not move it into a random form fragment, change the function name, or try to use it to retrieve the language when the task is to translate a displayed value. After adding it, open the view on every language-specific page using the same test entry. Confirm that the selected entries remain available and that visible text now matches the page. If output becomes empty or a technical code is translated, restore the previous template and recheck the field's purpose.

Check Public Data Without Exposing More Than Necessary

A view on the public side of a site requires particularly careful testing. A form may correctly accept an inquiry while displaying data on a page available to a broader audience. Before publication, decide which fields may be shown at all. A visitor's name, email address, and message generally should not be used as content for a public list without a clear purpose and an appropriate process. A neutral test entry with fictitious data is sufficient for technical verification.

Open every language-specific view page and review two outcomes: does the visible text match the locale, and has internal information intended for conditions or the team appeared in the output? If the template displays an inquiry topic, make sure visitors see a clear label rather than support. If a technical code is needed only for filtering, keep it hidden. This separation makes both localization and view maintenance less stressful.

A Safe Order for Moving a Form

For imports and exports, treat the form, pages, and translations as separate migration layers. First move the field structure itself and check that it opens in Formidable. Then verify separate saved values, the hidden language field, and actions. After that, restore strings and language-page relationships through Polylang. Finally, publish the form at test URLs and run verification submissions. Order matters more than speed: the import may finish technically, but the multilingual setup is only ready after the final step.

Before moving the form, record the current field names, option values, shortcodes in use, and action list. You do not need to save all email text in a note if project policy prohibits it, but you should be able to compare conditions and recipients. After import, do not rename every element "for consistency" before testing. First prove that the migrated version reproduces the original behavior, then perform deliberate cleanup. Otherwise, it will be impossible to distinguish import effects from later manual changes.

Migrating One Language as a Control Step

If a site has many forms and languages, do not migrate everything as one untestable package. Choose one form with a clear structure, one additional language, and one notification route. Restore Polylang strings, create the linked page, confirm language storage, and submit a test. Once you have a working reference example, use it as the sequence for the remaining forms. This does not guarantee automatic compatibility for every complex form, but it reduces the number of unknowns at the same time.

After migration, separately check old links to pages containing forms. Even a correct translation will not help if a menu, button, or language switcher still points to the old URL. Follow the path from a normal public page to the form in every language, not just a direct link from the admin area. If the visitor path works and the entry and email match the reference example, the migration can be considered confirmed for that form.

When Formidable Forms Polylang Multilingual Is a Good Choice

This integration suits a site that already uses Polylang and needs a localized form interface, stable values, and manageable post-submission actions. Its strength is a transparent setup: the page establishes the language, the form displays the translation, the hidden field records context, and conditions select the response.

Before launch, test one realistic visitor path from the language-specific page to the email. If it works in every required language, you can download the Formidable Forms Polylang Multilingual archive and apply this process to the remaining forms. If the test fails, do not add new languages or fields until the specific broken link in the chain has been resolved.