How to Translate Gravity Forms in WordPress – Fields, Notifications, Confirmations, Conditional Logic

Before You Start

Install and activate these plugins:

• Gravity Forms.
• WPML and WPML String Translation.
• GFML – Gravity Forms Multilingual (the add-on this page covers).

Build the form in Gravity Forms in your site’s source language. Add every field you want (Pricing Fields, paginated structure, Conditional Logic, Notifications, and Confirmations) before sending the form for translation. You can always change 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

1. Open WPML > Translations > Dashboard.
2. Expand the Gravity Forms section.
3. Tick the form you want to translate.
4. Choose a translation method: PTC (recommended), your translator, or Translate myself.
5. Click Translate.

The form, its fields, options, Notifications, Confirmations, and per-field validation messages all come into the same translation job. Translators see them as labelled rows in the Advanced Translation Editor.

Insert the Form Into Your Translated Pages

Gravity Forms sits inside a page or post, usually through the Gravity Forms block or the [gravityform id="X" title="false"] shortcode. The way you handle multilingual insertion is the bit that surprises clients most, so here’s the rule:

Use the same block or shortcode on every language version of the page. Don’t create a separate form per language.

The flow:

1. Build the form once in your source language.
2. Send the form for translation (or let Translate Everything Automatically pick it up).
3. Insert the form on the source-language page using the Gravity Forms block or the [gravityform] shortcode.
4. Translate the page through WPML > Translations > Dashboard the same way you’d translate any other page. The form embed is preserved in the translated page.
5. When a visitor lands on the translated page, GFML 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 need to swap shortcodes per language. The translation is linked to the source form; the glue plugin resolves the right-language version at render time based on the page’s language.

The exception – when you genuinely want different forms per language. Some sites need structurally different forms per language (different fields, different logic, not just different copy). In that case, build separate Gravity Forms (one per language) 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.

Field Labels and Options Translate Alongside Pricing and Product Fields

Every field label, placeholder, dropdown option, radio choice, checkbox label, and HTML field content appears in the translation job. For Gravity Forms’ distinctive Pricing Fields (Product, Quantity, Total, Shipping), the labels translate too – “Quantity” becomes “Quantité” – while the underlying numeric handling stays untouched. List fields, Digital Signatures, and File Uploads translate the same way. Multiple Choice and Image Choice (Gravity Forms 2.9 field types) translate from GFML 1.8.3 onwards.

Paginated Forms and Conversational Forms

For paginated forms, every page heading and page-break title sits in the translation job. Conditional Logic that branches across pages survives translation. Choice values stay aligned across languages, so the show/hide rules keep firing on the same data. Conversational forms (the one-question-at-a-time mode) translate every prompt and every transition. Pick one language version, walk through the conversational flow, and confirm each step reads naturally before publishing.

Per-Field Validation Messages

Each field in Gravity Forms has its own Validation Message setting in the field’s Advanced tab – the text shown when validation fails. Each one appears as a row in the Advanced Translation Editor.

If you don’t see a per-field validation message in the translation job, the field is probably using Gravity Forms’ default message (set in Forms > Settings > Form Settings) rather than a per-field override. Either set a custom per-field message and re-send the form for translation, or translate the global default via WPML String Translation.

Confirmations – Text, Redirect, and Page

Gravity Forms supports three Confirmation types and all three work multilingually:

• Text confirmations translate inline. Edit the source-language confirmation in Gravity Forms > re-send the form for translation > translated text appears for each language.
• Page confirmations point to a WordPress page. Translate that page through WPML’s normal page-translation workflow; the visitor sees the language version that matches their context.
• Redirect confirmations send the visitor to a URL after submission. The URL itself is translatable per language. Set a different thank-you URL for each language in the Advanced Translation Editor.

Notifications and Notification Routing

Every Gravity Forms Notification translates per language: To Email, From Name, Subject, body templates, and merge tags. The Notification body uses Gravity Forms merge tags ({Name}, {Email}, {All Fields}) and these resolve correctly after translation. Notification routing rules send different submissions to different recipients based on field values. They survive translation because the underlying choice values stay aligned across languages.

After translation, send a test submission in each language and confirm the notification arrives in the visitor’s language with the right merge-tag substitutions.

Conditional Logic on Translated Choice Values

Conditional Logic on text-based choices (Radio Buttons, Checkboxes, Dropdowns) keeps working across translations because GFML maintains a value map between source and translated labels. The visitor sees “Pas encore” in French; the underlying value stays “Not yet”; the conditional rule keeps firing on “Not yet”.

The one thing that breaks Conditional Logic: changing the source-language choice label after translation without re-sending the form for translation. The mapping goes stale. Fix it by re-sending the form – GFML updates the value map.

Integration Add-Ons – Mailchimp, ActiveCampaign, HubSpot, Zapier, Slack, Webhooks

Gravity Forms add-ons that push submissions to third-party services (Mailchimp, ActiveCampaign, HubSpot, Zapier, Slack, Webhooks, and the rest) receive the translated visitor input. A French visitor’s name and message arrive in French at the destination. Mapped list labels, pipeline stages, and channel names translate too if they live as form-level strings.

If your integration uses field values rather than labels (e.g., mapping a dropdown value to a Mailchimp list), the value stays canonical across languages so the mapping doesn’t break.

Common Pitfalls

• Choice labels don’t translate in notification emails. Re-send the form for translation after changing the source-language labels. If the problem persists, check that GFML is up to date. This was a recurring issue on older versions and is tracked on the forum threads.
• Form Block styling looks wrong on translated pages. Known styling regression – see the errata page. Workaround: use the standard [gravityform] shortcode embed rather than the Form Block while a fix is pending.
• Form shows “There is nothing to translate” when there obviously is. Usually a Dashboard cache issue. Refresh the page, or re-send the form for translation from the post that embeds it.
• Conditional Logic stops firing in translated forms. A choice label was edited in the source language after translation. Re-send the form for translation to refresh the value map.