Formidable Polylang - WordPress Plugin

Formidable Polylang Guide: Translating Forms, Emails, and Messages in WordPress

Formidable Polylang is not meant for translating an entire website. Its job is much more specific: connecting Formidable Forms to Polylang's language logic so visitors see the form, field choices, confirmation message, and emails in the correct language. This guide walks through the practical workflow, from site preparation to submission testing, instead of repeating the product's short description.

The main focus here is on the things that commonly break in multilingual forms: dropdown values, sending emails in multiple languages, post-submit confirmations, displaying selected values in Views, and how pages created through Polylang behave. The guide includes safe PHP snippets, but only where they are supported by Formidable and Polylang documentation and genuinely help solve the problem.

If you already have a WordPress site running Polylang and Formidable Forms, you can use this guide as an implementation checklist. If the site is only now being prepared for translation, start with the sections on dependencies, language structure, and separate saved values. Those decisions are best made before the forms go live on production pages.

What this plugin actually solves

On a multilingual WordPress site, a form is rarely just a set of visible labels. It also includes fields, choice options, system messages, an email to the administrator, an email to the visitor, a post-submit confirmation, and sometimes a View that displays the submission or selected value. Polylang translates pages, posts, taxonomies, menus, widgets, and strings, but a form created in a separate builder has its own internal structure. That is exactly where Formidable Polylang comes in.

The official Formidable documentation describes the plugin as a way to translate forms through Polylang using a dedicated add-on. In practice, that means you are not just duplicating a page in another language. You open the settings for a specific form, click Translate Form, enter the translations, and then publish the form on pages that are already linked through Polylang. It is important to understand the boundary here: the plugin helps Formidable Forms work inside a multilingual setup, but it does not replace translation editing, and it does not turn every form string into an automatic translator.

The biggest strength of this approach is control. A contact form can have simple labels in two languages. A more complex application form with radio buttons, checkboxes, and dropdowns can keep stable saved values while showing localized labels to the visitor. For emails, you can create separate actions for each language and enable conditional logic so every email is not sent at once.

Where Formidable Polylang is especially useful

This plugin makes the most sense when the form is part of an actual user workflow, not just a decorative page block. For example, on a language school website, the enrollment form should change the field language while still feeding submissions into a single CRM workflow. On an agency website, a project brief form can keep the same internal service values while displaying different labels to visitors from different locales. In an event directory, the user can choose a participation type in their own language while the administrator receives a predictable value for sorting submissions.

Formidable Polylang is also useful on sites where the post-submit confirmation matters. If a visitor fills out a French page, they should not see an English "Thank you." If an administrator receives a submission from a German page, the email subject and key fields should clearly show where the request came from. At that point, this is no longer just a visual issue. It affects support quality, submission processing speed, and trust in the form itself.

What it does not do for you

The plugin does not eliminate the site owner's basic responsibilities. You still need to configure languages in Polylang ahead of time, connect translated pages, place forms on the correct page versions, test email delivery, configure WordPress mail delivery, and make sure the theme does not hide the language switcher. It also does not automatically solve business logic where different languages require different recipients, attachments, or consent text. For those cases, you use Formidable actions, conditional logic, and a hidden field that stores the current language.

Practical takeaway: Formidable Polylang should be treated as a bridge between the form and the site's language structure. It helps translate Formidable elements, but the quality of the result depends on how carefully you separate visible labels, saved values, emails, and Polylang pages.

Who Formidable Polylang is for, and when a different path makes more sense

The best fit for Formidable Polylang is a site that already uses Formidable Forms as its main form builder and Polylang as its main multilingual layer. If those two tools are already part of the project, the dedicated add-on is usually a more logical choice than maintaining manual form duplicates, writing custom template conditions, or switching to another translation tool just for forms.

The plugin is especially appropriate for site owners, agencies, and developers who want to keep a single Formidable system: submissions, entries, notifications, confirmation actions, Views, field IDs, and familiar shortcodes. That reduces the risk of confusion when the English form lives in one plugin, the French form lives in another, and the administrator later has to collect submissions from different places.

Good-fit scenarios

• Contact forms where the visitor selects a language through Polylang and Formidable displays localized labels and messages.
• Application forms with checkboxes, radio buttons, and dropdowns where visible labels need to stay separate from saved values.
• Forms with separate email actions by language, where the message needs a different subject, text, or recipient.
• Sites using Formidable Views where the selected value needs to be displayed in a localized format.
• Projects where the administrator wants to store all submissions in one place while serving visitors in multiple languages.

When to think twice

If the site does not use Formidable Forms yet and the forms are simple, a translation plugin that can translate the visible page as a whole may be enough. If you need fully automatic machine localization for all forms without manual editing, Formidable Polylang may feel too hands-on. If the project is built around WPML, it makes more sense to compare Formidable's native WPML integration. And if the main goal is translating WooCommerce pages, products, and store emails, then Formidable Polylang should not become your central solution. It covers Formidable forms, not the entire store.

There is also an organizational side to this. Translating a form is not a one-click task. Every new field option, new email, new confirmation action, and new error message has to be tested again in every language. That is why the plugin is a good fit for teams that are ready to manage forms as a real product layer of the site, not as something they "set once and forget."

What to check before installation

Preparation matters because multilingual forms do not break only because of the add-on. More often, the problem starts earlier: Polylang is not configured, pages are not linked as translations, Formidable is outdated, forms use identical saved values, WordPress email is not being delivered, or editors are only updating one language version of the page.

Before installation, make sure the site already has a working language model. In Polylang, the languages should be added, a default language should be set, the URL format should be configured, and there should be either a language switcher or clear navigation between translations. If the base page in the second language does not even open properly yet, it is better to postpone form translation. Otherwise, you will be troubleshooting multiple layers at once.

Minimum dependencies

Formidable documentation notes that access to the add-on requires the appropriate Formidable Forms license level, and the installation sequence itself includes Polylang, Formidable Forms Premium, and enabling the add-on on the Formidable > Add-Ons page. In practice, that means you should confirm three things before starting configuration:

• Polylang is installed, activated, and already managing the WordPress site's languages.
• Formidable Forms Premium is installed and connected so approved add-ons are available on the add-ons page.
• Formidable Polylang is enabled as an add-on, not just assumed to be a built-in Polylang feature.

Do not start with a live production form. Create a short test page in two languages and a simple form with a name field, email field, dropdown, and message field. That kind of form reveals nearly all the key risks: label translations, saved values, publishing on Polylang pages, the confirmation message, and the email action.

Saved values before translation

Separate saved values are a critical setting for checkboxes, radio buttons, and dropdowns. Formidable recommends using distinct saved values that differ from option labels when those fields will be translated. The reason is simple: the visible label changes by language, but the saved value should stay stable. That way, conditional logic, calculations, View filters, and emails do not fall apart because "Support" turned into "Support" in another language or "Assistance."

If you already created the form without separate values, do not translate it right away. First open the choice fields, enable Use separate values, assign unique saved values, and review the existing conditions. A solid pattern is this: the visible label is localized, while the saved value stays a short technical slug such as sales, support, or billing. You do not need to expose those slugs to the user, but they give the administrator a stable foundation for conditions.

Email delivery and a test environment

Multilingual emails are hard to validate if WordPress mail itself is unstable. Before configuring separate email actions, submit a regular test entry from the base form and make sure the email arrives. If it does not, fix delivery first by checking the From address, Reply-To, SMTP, or your hosting mail policy. Otherwise, you may assume the language condition is failing when in reality Formidable cannot send any email at all.

For a production site, using a staging copy is the safer approach. There you can change saved values, add a hidden field, enable snippets, and test whether the existing entry workflow still behaves correctly. If you do not have staging, make a backup and start with a new test form, not with a form that is already receiving leads from ads.

Installing the add-on and running the first check

Installing Formidable Polylang has three logical steps: install Polylang, make sure Formidable Forms Premium is active, and then enable the add-on on the Formidable page. Do not mix this stage with translating all forms. First, you want a predictable technical status: the add-on is enabled, the translation button appears, and the test form opens in the editor without errors.

Action order in the admin panel

1. Open Plugins and make sure Polylang is active.
2. Check the base languages in Polylang and create a translation of the test page.
3. Make sure Formidable Forms Premium is active and the Formidable > Add-Ons page is available.
4. On the add-ons page, enable Formidable Polylang.
5. Open the test form, go to Settings > General, and confirm that the Translate Form button is present.

If the translation button does not appear, do not jump straight into code edits. Check whether Polylang is active, whether the add-on is enabled, whether the form is open in a cached browser tab, and whether the current user can access the required Formidable pages. Sometimes a simple admin page refresh after enabling the add-on is enough, but if a dependency is inactive, the button will not appear on its own.

The first form to test with

Create a small form: name, email, subject, and message. For the subject field, use a dropdown with three options: consultation, support, and partnership. Assign the saved values consulting, support, and partner. This kind of form is simple for the user, but still gives you enough coverage to test option label translation and future conditions.

Place the form on the default-language page, then create the translated page through Polylang. At this stage, do not add complex confirmations, redirects, or multiple email actions. Your goal is simply to verify that the form renders, the page opens in each language, and the translation button is available in the form settings.

Do not start configuration with a payment form, registration form, or long questionnaire. First validate the basic cycle on a simple form: translation - publishing - submission - entry recording - email - confirmation.

How to translate a form without breaking field logic

In Formidable Polylang, form translation revolves around the Translate Form button in the form settings. After clicking it, you enter the translations and save the changes. Visually, that feels straightforward, but the quality of the result depends on how the fields are structured. This matters most for choice-based fields, because they contain both visible text and a saved value.

Text fields and labels

For regular text, email, and textarea fields, the logic is simple: you translate the label, placeholder, help text, and any other visible strings used in the form. Check them not only in the editor, but also on the public page. A WordPress theme, Formidable styles, and container width may behave differently with longer German or French phrases. If a label becomes too long, it is usually better to rewrite the phrasing than to shrink the font across the entire form.

Do not try to translate technical field keys if they are used in shortcodes, integrations, or conditions. Human-facing text should be localized, but the form's technical identity should remain stable. That makes support easier, especially when the form is maintained by someone other than the person who translated it.

Checkboxes, radio buttons, and dropdowns

Choice fields require more discipline. Formidable explicitly recommends using separate values for checkboxes, radio buttons, and dropdowns that differ from the option labels. In a multilingual form, this is not just a convenience. It is how you avoid errors. Imagine a "Department" field where the visitor sees "Sales," "Support," and "Billing" on the English page and localized versions on another page. If the saved value matches the visible label, your email action condition has to be maintained separately for every language. If the saved value is always sales, support, or billing, the conditions stay stable.

After enabling separate values, check where those values are used. They may appear in emails, confirmation messages, Views, CSV exports, integrations, and calculations. If the visitor needs to see the localized label, use the normal label output. If the administrator needs a stable slug, output the saved value. Do not mix those two jobs in the same field without a clear reason.

What to check after saving translations

After translating the form, open every language page in a private browser window. Do not test only from the admin panel: administrators may have language preferences, the WordPress admin bar enabled, and caching behavior that regular visitors do not see. Submit a test entry in each language and check three places: the public confirmation, the record in Formidable > Entries, and the email.

If the correct saved value is stored in the entry but the page shows the wrong label, the issue is usually in the label translation or page publishing. If the email contains the wrong text, inspect the email action and conditional logic. If the form does not render on the translated page, make sure the Polylang page is actually linked to the source page and contains the shortcode for the correct form.

Emails in different languages: hidden field, shortcode, and conditions

Translating the visible form is easier than translating emails. An email does not always know which language page the user came from. Formidable documentation recommends using a current-language shortcode, storing it in a hidden field, and then creating separate email actions by language. This is one of the most important Formidable Polylang workflows, because email is often where careless localization becomes obvious.

The logic works like this: Polylang knows the current language, a PHP snippet returns the language slug, Formidable stores it in a hidden field, and email actions use conditional logic. For an English submission, the action with the condition language equals en will run. For a French submission, the action with language equals fr will run. If you use different slugs, take them from Polylang rather than making them up manually.

A safe shortcode for the current language

Formidable shows an example shortcode, [get_current_language], that returns the current language through the Polylang function pll_current_language('slug'). Polylang warns in its documentation that you should check whether plugin functions exist before using them, so the site does not break during an update or temporary Polylang deactivation. That is why the guarded version is safer:

add_shortcode( 'get_current_language', 'site_get_current_polylang_language' );

function site_get_current_polylang_language() {
    if ( ! function_exists( 'pll_current_language' ) ) {
        return '';
    }

    return pll_current_language( 'slug' );
}

Add code like this through a snippets plugin, a child theme, or your own mini-plugin. Do not edit WordPress core, Formidable files, or Polylang files. After adding the code, create a hidden field in the form and set [get_current_language] as its default value. Then submit a test entry and make sure the language value appears in the entry.

How to validate the hidden field

1. Open the form on the default-language page and submit a test entry.
2. Open the record in Formidable > Entries and locate the hidden field.
3. Repeat the submission on the other language page.
4. Compare the values. They should match the language slugs defined in Polylang.

If the hidden field is empty, check whether the Polylang function exists, where the snippet was added, and whether the shortcode is actually set as the default value. If the field shows the same language on every page, review the Polylang page connection and the way language switching is configured.

Separate email actions

In Formidable, email actions are configured under Settings > Actions & Notifications. For a multilingual form, create a separate email action for each language and then enable conditional logic. The point is not to duplicate everything for the sake of duplication. The point is to give each email its own subject, greeting, body text, signature, and, if needed, recipient.

For example, the English response action gets the condition: hidden language field equals en. The French one gets equals fr. If you use Russian, that might be ru, assuming that slug is defined in Polylang. Do not use full language names in the condition if the hidden field returns the slug. Otherwise, the action will never trigger.

Common email mistakes

The most common mistake is creating multiple email actions and forgetting the conditions. In that case, every email goes out after every submission. The second mistake is pointing the condition to a visible language-selection field that the visitor never changed instead of the hidden field. The third mistake is storing the language label in the hidden field while the conditions expect the slug. All three issues are easiest to diagnose through the entry: first check the actual stored value, and only then adjust the email actions.

If no email arrives at all, do not start with translation. Check standard mail delivery first: the From address, Reply-To, SMTP, spam folder, mail logs, and a basic email without conditions. In its notifications documentation, Formidable also recommends testing email notifications after configuration. With a multilingual form, that test should be repeated for every language.

Post-submit confirmations: how to show the right message

The confirmation message is the first thing the visitor sees after submitting the form. If the form is translated but the confirmation remains in the default language, the site immediately feels unfinished. Formidable Polylang documentation recommends creating separate confirmation actions by language and triggering them conditionally, just as you do with emails.

How to structure confirmation actions

Create a hidden field for the current language the same way you did for emails. Then, under Settings > Actions & Notifications, add a confirmation action for each language. In each action, choose to display a message, write the message in the correct language, and set conditional logic based on the hidden field. Only one confirmation should fire for each language.

Do not create one universal confirmation message containing a long block of multiple languages. It looks messy and makes analytics harder. A short localized message works better: a thank-you, what happens next, when to expect a response, and where to write if the request is urgent. If the form should redirect after submission, make sure the URL points to the correct language page, not the default one.

Checking the result on the site

After configuration, open each language page in a private window, fill out the form with different test data, and submit it. Immediately capture four outcomes: which confirmation text appeared, which entry was stored, which email was sent, and which page opened after submission. This small validation matrix finds mistakes much faster than trying to guess what looks off.

If you are using AJAX submission, also verify that the confirmation message appears without reloading the page and does not mix in text from another language. If the behavior is inconsistent, temporarily disable AJAX on the test form and compare the result. If everything works correctly without AJAX, then look for a conflict in the theme, script optimization, or caching.

Displaying values in Views and other parts of the site

Some forms do not end with an email. Formidable is often used for directories, applications, profiles, reviews, events, and internal dashboards. In projects like these, a user-selected value may be displayed in a View. The official Formidable Polylang documentation describes the [translate_value] shortcode, which uses the Polylang function pll__() to translate a value before output.

This is not needed in every case. If you are already translating labels and options, an additional translation pass may be unnecessary. But if the View displays a saved value that should look human-readable in the current language, this shortcode helps. It is especially useful for lists where the administrator wants to store a stable slug while visitors see localized text.

When to use translate value

Use this approach only after you understand exactly what is being displayed: a label, a saved value, or a field label. If the View already receives the localized label, adding another translation step may create confusion. If the View receives a technical saved value, first register the matching strings in Polylang or make sure they are available for string translation. Otherwise, pll__() will return the original value, and you may think the shortcode is broken.

A safe version of the shortcode can look like this:

add_shortcode( 'translate_value', 'site_translate_polylang_value' );

function site_translate_polylang_value( $atts ) {
    $atts = shortcode_atts(
        array( 'value' => '' ),
        $atts
    );

    if ( ! function_exists( 'pll__' ) ) {
        return $atts['value'];
    }

    return pll__( $atts['value'] );
}

Test the shortcode in a dedicated View first. Insert a field value, open the page in two languages, and make sure only the display changes, not the stored data. If the string is not translating, check the string translations section in Polylang and confirm that the string is registered for translation.

Importing and exporting translations

Formidable documentation explicitly states that Formidable does not manage translations during form import and export. Translation strings have to be handled through Polylang tools. Polylang Pro supports importing and exporting string translations in PO and XLIFF formats. This matters for agencies and larger sites where translation work is handled by an editor or an external team.

If you have multiple environments, such as staging and production, do not rely on memory alone. Document which form strings are translated through Formidable Polylang, which go through Polylang strings, which live inside email actions, and which are written directly in page content. That map may feel unnecessary when you only have two languages, but it can save the project when more languages are added or the form needs to be moved to another site.

Practical example: a bilingual support request form

Let us walk through a specific scenario. The site has English and French versions of the support pages. You need one Formidable form with translated visible fields, visitor emails sent in the page language, a localized confirmation, and stable saved values for the support department workflow.

Goal

The visitor opens the support page in their language, sees the fields in that language, selects a request type, submits the form, and receives a confirmation in the same language. The administrator sees the entry in Formidable, where the request type is stored as a stable value. The visitor email is sent only in the correct language version.

Preparation

• Languages are set up in Polylang, and the support pages are linked as translations.
• Formidable Forms Premium and Formidable Polylang are active.
• Separate values are already enabled for the request type field.
• The [get_current_language] snippet has been safely added through a snippets plugin or child theme.
• WordPress mail has already been tested with a standard email action that has no conditions.

Configuration steps

1. Create a form with the fields Name, Email, Request type, Message, and a hidden field called Current language.
2. For Request type, set visible options such as Technical support, Billing question, and Partnership, and use support, billing, and partner as the saved values.
3. Set the hidden field default value to [get_current_language].
4. Open Settings > General, click Translate Form, and translate the labels, placeholders, and options.
5. Create an email action for the English visitor response and add the condition hidden field equals en.
6. Create an email action for the French visitor response and add the condition hidden field equals fr.
7. Create separate confirmation actions for en and fr.
8. Place the form on the default-language page and on the translated page created through Polylang.

Validation

Open the English page in a private window. Fill out the form, choose a request type, and submit it. Confirm that the confirmation message is in English, the entry contains en in the hidden field and a stable saved value in the request type field, and the email was sent only by the English action. Repeat the same test on the French page. If both emails are sent, the conditions are not limiting the actions. If neither email is sent, inspect the actual hidden field value in the entry.

A subtle but important detail

If the translated page exists but the form still behaves like the default language version, do not look only at Formidable. Sometimes the problem is that the translated page contains the form shortcode but is not actually linked to the original Polylang page, or the visitor lands on a URL without the correct language context. In that case, Formidable receives a different language context than the one you expect.

Settings worth tracking as a working map

There is no single "best configuration" for Formidable Polylang across every site. The right setup depends on the role the form plays. But there is a working map that is worth maintaining for every important form. It helps you avoid losing track of where text lives and what needs to be retested after changes.

The form text map

Divide all strings into groups. The first group is visible labels, placeholders, and help text inside the form. The second is options for checkboxes, radio buttons, and dropdowns. The third is confirmation messages. The fourth is email subjects and messages. The fifth is strings displayed in Views or templates. The sixth is system errors and user-facing messages, if they exist.

For each group, note how it is translated: through Translate Form, through separate Formidable actions, through Polylang strings, through a View shortcode, or through a dedicated snippet. This table does not have to live inside the plugin. A standard project document is enough. The important thing is that the next editor can understand why a label is translated in one place while an email is translated somewhere else.

The condition map

Conditions should point to stable values. For language, that means a hidden field containing the language slug. For choice fields, it means the saved value. For complex forms, it may mean a separate status field or request-type field. Do not build conditions on localized text that an editor can change later. That is fragile and hard to troubleshoot.

If the form sends different emails depending on both language and department, do not let the conditions turn into a mess. First check the language, then the department, then the recipient. In larger forms, it is often cleaner to have separate actions by language and then add careful department-specific conditions within those, rather than one action with a long chain of ambiguous rules.

The post-change validation map

Every form change should go through the same short test: open the page in each language, submit an entry, check the entry, check the email, check the confirmation, and check the View if one is used. If the form is connected to a CRM, spreadsheets, or webhooks, include those in the test. Do not consider the setup complete until you have verified the result from the outside, not just inside the admin panel.

When Formidable Polylang is the right choice

Formidable Polylang is worth using when the site already runs on Formidable Forms and Polylang together, and the form needs to be a real part of the multilingual user journey. A good result looks like this: the visitor lands on a page in their language, sees clear fields, chooses options in that language, receives the correct message after submitting, and the administrator gets a predictable entry and email.

Before going live, run one short final check: the add-on is enabled, Translate Form is available, separate values are defined for choice fields, the hidden field stores the language slug, and the email actions and confirmation actions are limited by conditions, and a test submission succeeds in every language. If all of that checks out, you can move on to the production form and gradually apply the same workflow to the rest of the site's forms.

If you are ready to test the product on your own project, the natural next step after reading this guide is to download Formidable Polylang, deploy it on a test form first, and only enable it for important submissions after successful validation. That order takes a little more time up front, but it saves hours of troubleshooting later in emails, translations, and conditional logic.