How to Translate WPForms in WordPress – Form Templates, Form Pages, Confirmations, Notifications
Learn how to translate every part of a WPForms form on your WordPress site into every language your visitors speak. This guide covers fields, Form Templates, Multi-Page Forms, Smart Conditional Logic, Validation Messages, all three Confirmation types, Form Notifications, payment add-ons, and the marketing integrations WPForms feeds. It walks you through the WPForms workflow with WPML and the WPForms Multilingual add-on.
Before You Start
Install and activate these plugins:
- WPForms (Lite or Pro).
- WPML and WPML String Translation.
- WPForms Multilingual (the add-on this page covers).
Build the form in WPForms in your site’s source language, including any Multi-Page structure, Smart Conditional Logic, Validation Messages, Confirmations, and Notifications you want, before sending the form for translation. You can revise the form later and re-translate the differences.
Translate Everything Automatically Handles This for You
If your site has Translate Everything Automatically turned on, you don’t need to send the form for translation manually. WPML picks up new and updated forms alongside the rest of your content and translates them in the background. The page-insertion step below still applies, but the send the form for translation step is automatic. The rest of this page describes the manual path for sites on Translate Some: You Choose What to Translate (or for forms you want to translate ahead of the automatic queue).
Send the Form for Translation
- Open WPML > Translations > Dashboard.
- Expand the WPForms section.
- Tick the form you want to translate.
- Choose a translation method: PTC (recommended), your translator, or Translate myself.
- Click Translate.
The form, its fields, options, Confirmations, Notifications, and Validation Messages all come into the same translation job.
Insert the Form Into Your Translated Pages
WPForms sits inside a page or post, usually through the WPForms block or the [wpforms id="X"] shortcode. The multilingual insertion rule is simpler than it looks:
Use the same block or shortcode on every language version of the page. Don’t create a separate form per language.
The flow:
- Build the form once in your source language.
- Send the form for translation (or let Translate Everything Automatically pick it up).
- Insert the form on the source-language page using the WPForms block or the
[wpforms]shortcode. - Translate the page through WPML > Translations > Dashboard the same way you’d translate any other page. The form embed is preserved on the translated page.
- When a visitor opens the translated page, WPForms Multilingual serves the form in the visitor’s language automatically – same form ID, same shortcode, translated content.
You don’t need a different form ID per language. You don’t swap shortcodes manually per language. The translation is linked to the source form; WPForms Multilingual resolves the right-language version at render time.
The Form Pages exception. Form Pages built with the Form Pages Addon translate through the same flow. Translate the page that hosts the form layout, and the form ID resolves to the visitor’s language.
The exception – when you genuinely want different forms per language. If you need structurally different forms per language (different fields or different logic, not just different copy), build separate WPForms forms and insert each one’s shortcode on the matching language version of the page using the WordPress editor for that translation. That’s the only situation where shortcodes diverge across languages.
Page-Builder Gotcha
If your page is built in Divi, Elementor, or another page builder whose text module wraps the shortcode, the shortcode may not always survive translation cleanly. Clients on Divi have reported this to our support team. If the translated page shows the source-language form, open the translated page in the page builder and re-insert the form’s block or shortcode in the builder. The native WordPress block editor and classic editor don’t have this issue.
Form Templates and Multi-Page Forms
If you built the form from one of WPForms’ Form Templates, the field set, default labels, and pre-wired Notifications all carry into the translation job. Translate once; every form you build from that template inherits the wiring.
For Multi-Page Forms, each page heading, intro paragraph, and navigation button (Next, Previous, Submit) translates as its own row. The progress indicator copy translates too. Walk through the multi-page flow in each language after translation to confirm the page-break labels read naturally.
Smart Conditional Logic
Smart Conditional Logic survives translation because WPForms Multilingual keeps a value map between source and translated choice labels. Visitors see translated labels; the underlying rule still fires on the canonical value. If you change a source-language label after translation, re-send the form so the value map updates.
Form Pages – Translate the Landing Page, Not Just the Form
The Form Pages Addon turns a form into a full landing page. After you’ve built the Form Page in WPForms, translate the WPForms form through WPML > Translations > Dashboard. That catches the field labels and Notifications. The Form Pages-specific strings (headline, intro copy, post-submission success state, footer message) live as WPForms Form Page settings and also translate through the same job. After translation, visit the page in each language and confirm every layer is in the visitor’s language.
Validation Messages
WPForms exposes two layers of Validation Messages:
- Global validation copy under WPForms > Settings > Validation: required-field error, email format, URL format, number range, file extension, file size, and the rest. Each translates as its own row in the Advanced Translation Editor.
- Per-field validation overrides. Set on individual fields, used when the global default doesn’t fit. These translate the same way.
Confirmations – Message, Show Page, Go to URL
WPForms supports three Confirmation types and all three work multilingually:
- Message. Inline thank-you text. Translates as a row in the translation job.
- Show Page. Redirects to a WordPress page. Translate that page through WPML’s normal page-translation workflow; visitors see the language version that matches.
- Go to URL (Redirect). External redirect after submission. The URL is translatable per language. Set a different thank-you URL for each language.
Conditional Confirmations (rules that show different confirmations based on field values) translate alongside.
Form Notifications
Every Form Notification translates per language. Send To Email, Email Subject Line, From Name, Reply-To, and Message all appear in the translation job. The Notification body uses WPForms Smart Tags ({field_id}, {name}, {email}) and these resolve correctly after translation. Conditional Notifications (the rules that route emails based on field values) survive translation because the underlying choice values stay aligned across languages.
For User Registration flows, the registration confirmation email translates to the visitor’s language as of WPForms Multilingual 0.5.0. Confirm by registering a test user from a translated page.
Payment Add-Ons – Stripe Pro, PayPal Commerce, Square Pro, Authorize.Net
Payment add-on copy translates through the same job. All the visitor-facing strings sit in the translation job: button labels (Pay $50 with PayPal), card-field validation messages, post-payment success copy, and error states. After translation, run a test payment in each language using the payment processor’s test mode and confirm the receipt copy lands in the visitor’s language.
Marketing and CRM Integrations
When a visitor submits a form in their language, the WPForms add-on that pushes the submission to Mailchimp, AWeber, Constant Contact, Drip, GetResponse, HubSpot, Salesforce, Klaviyo, ActiveCampaign, or Zapier receives the translated visitor input. Mapped fields (list, tag, pipeline stage) translate if they live as form-level strings; field values stay canonical so the mapping doesn’t break.
A Note on the Calculations Addon
The WPForms Calculations Addon is currently incompatible with WPForms Multilingual. Calculation logic doesn’t run when both are active. See the errata page. If your form needs Calculations, plan around this limitation until the compatibility is resolved.
Common Pitfalls
- Wrong-language confirmation emails. Confirm WPForms Multilingual is on version 0.5.0 or later. Earlier versions had a recurring issue tracked on the forum thread.
- Form-saving interference. Old versions caused issues with saving the form after translation. Resolved in 0.4.1 (Dec 2024) – upgrade if you see this.
- Smart Conditional Logic stops firing after a label edit. Re-send the form for translation so the value map updates.
- Add-on strings missing from the translation job. Some less-common WPForms add-ons may not register strings into the job. Use WPML String Translation to translate any orphan strings. If a specific add-on is consistently missing strings, report it on the WPForms compatibility page.
Written by Amir · Last updated July 2, 2026