Gravity Forms Multilingual - WordPress Plugin

Guide to Setting Up and Testing Gravity Forms Multilingual

Gravity Forms Multilingual is not meant for building a separate form for every language. Its purpose is to translate existing Gravity Forms cleanly inside a multilingual WordPress site. This guide walks through the practical steps: what to prepare before installation, how to send a form for translation through WPML, and how to verify the fields, notifications, confirmations, form page, and submission data.

The core idea behind the product is simple, but real-world use comes with plenty of details. Translating only the field label is not enough. The form may be embedded through a block or shortcode, an email may go out in the wrong language, conditional rules may depend on a field value, and page caching may show an outdated version. That is why this guide does not follow a promotional feature list. Instead, it follows an actual workflow: one source form - multiple languages - a verifiable outcome on the front end.

This guide is written for site owners, WordPress administrators, developers, and content managers who already use Gravity Forms and WPML or are evaluating whether this bridge between them is worth adding. It does not cover purchasing, licensing, or activation bypasses. The focus here is on configuring a product you already have access to, troubleshooting it, and testing it safely on a site copy.

What Problem This Plugin Solves on a Multilingual Site

Gravity Forms itself handles the form: fields, validation, post-submission messages, notifications, conditional logic, integrations, and submission entries. WPML handles the site's language layer: pages, posts, interface strings, translation through the editor, human translators, or automation. Gravity Forms Multilingual connects those two systems. It makes the text-based parts of the form available for translation inside WPML and helps display the form to visitors in the language of the current page.

This approach is especially useful when the form is already part of a working funnel: a service request, contact form, event registration, survey, quote request, support form, pricing calculator, subscription form, or internal brief. Without this integration, administrators often create a separate form for each language. That may look fast at first, but discrepancies start to appear over time: one version is missing an updated required field, another still shows an old helper note, and a third sends email to the wrong address. Keeping one source form reduces that risk.

At the same time, it is important to understand where the plugin's responsibility ends. It translates form elements and helps WPML select the correct display language. It does not turn every submission into a separately translated record, it does not automatically improve weak email copy, and it does not eliminate the need to translate the page where the form appears. If the form is embedded on an English page, but the Spanish version of that page has not been created or linked in WPML, the visitor may not get the language switcher behavior they expect. That is why this guide looks at form translation together with the page, shortcode, notifications, and final verification.

What Gets Translated Inside Gravity Forms

According to the official WPML documentation, this bridge can translate form titles, field labels, sub-labels, radio button options, checkboxes, dropdowns, confirmations, and notifications. In practical terms, that means translation should cover more than just the visible face of the form. It should also include what the user sees after submission and the email text received by the administrator or the submitter.

In long forms, the most common mistake is translating only the major labels and forgetting the microcopy. That includes placeholders, compound field sub-labels, text beneath the field, choice labels, the success message, the notification subject line, the email body, and utility words inside merge tags. A form is only truly translated when the user completes the entire journey in the target language: sees the fields, submits the data, receives a clear confirmation, and the team gets the correct notification.

When It Is Better Not to Create Separate Forms Per Language

Separate forms for each language can sometimes look like an easy fallback, but they make maintenance harder. If the business changes one field in the lead form, the administrator has to repeat that change in every language copy and then recheck every page, email, and integration. If the form is connected to a CRM or spreadsheet, the risk also increases that submissions from different languages will land in different data structures.

Using one source form is especially convenient for sites with many languages and forms that change from time to time. You update the structure in Gravity Forms and then refresh the translation in WPML. That does not remove the need for testing: when choice labels or conditions change, existing translations may need updates. Still, managing one form is easier than maintaining several near-identical forms that gradually drift apart.

Who This Translation Approach Fits Best, and When It May Be Inconvenient

Gravity Forms Multilingual works best on sites that have already committed to the Gravity Forms + WPML stack. If the site has a lot of content, multiple languages, editors already translate pages through WPML, and forms are part of the overall user journey, the integration is a logical fit. The team does not need a separate system for forms. It works with the same translation dashboard, the same languages, and the same publishing rules.

The plugin is also useful for agencies managing multiple WPML sites. They benefit from a repeatable workflow: create the form, send it for translation, verify the page, and document the process for the content team. It also fits sites where forms are updated by editors rather than developers. In that case, using the Advanced Translation Editor reduces the risk of breaking HTML, accidentally deleting a merge tag, or confusing a technical value with visitor-facing text.

There are also cases where this option may be unnecessary or awkward. If the site is monolingual and you only need to translate the Gravity Forms interface into Russian, WordPress language files and Gravity Forms itself are enough. If the site uses a multilingual plugin other than WPML, Gravity Forms Multilingual is not a universal bridge. And if the business intentionally wants different forms for different markets - different fields, different legal consent text, different notification routes - it may be simpler to maintain separate forms, but only if those differences are documented carefully.

Who Needs to Be Especially Careful

Sites with multi-step forms, conditional confirmations, payment fields, CRM integrations, and automated emails need to test more than the layout. Multilingual behavior affects which labels the user sees, which values are saved in the entry, what data is sent to an external service, and what language the email arrives in. The more complex the form, the more important it is to configure it on a site copy first and only then move changes into production.

If the form collects legally significant consent, personal data, or submissions for multiple regions, the translation should be reviewed by a human editor. Automatic translation saves time, but for legal text, medical questions, financial services, and data-processing terms, you should not rely on machine output alone. A required step is to verify the consent text, privacy policy links, and user-facing email in every language.

What to Check Before Installation and the First Translation

Do not start installation by clicking Activate. First, make sure the site actually has everything required for WPML and Gravity Forms to work reliably together. The official Gravity Forms Multilingual page lists the required components: WPML, WPML String Translation, Gravity Forms, and Gravity Forms Multilingual itself. WPML's requirements page separately highlights WordPress memory limits, PHP version, REST API functionality, the ability to create database tables, and the necessary PHP extensions. This is not just a formality. Translation through the editor and string synchronization can be demanding on weak hosting.

In practice, preparation is easier if you split it into four areas: the technical environment, language setup, the current state of the form, and where the form is displayed. That makes it easier to identify the cause if the form does not switch languages after translation or some text remains in the source language.

Technical Environment

Make sure WordPress, WPML, WPML String Translation, Gravity Forms, and Gravity Forms Multilingual are updated together. WPML explicitly warns in its release notes not to mix versions in a "part new, part old" state. That matters especially for form translation. Changes in Gravity Forms may affect new field types, block styling, or internal filters, and the bridge needs to know how to handle them.

• Open Tools > Site Health and check memory, PHP, REST API, and critical warnings.
• In WPML, confirm that the site languages are already configured and visible in the admin area.
• Make sure WPML String Translation is active, because some plugin and theme strings are translated through it.
• Update related components together rather than one by one with large version gaps.
• Before making changes on a live site, create a backup or work on a site copy.

The State of the Form Itself

It is best to get the form into a clean, understandable state in the source language first. If you are changing fields, options, rules, confirmations, and notifications while also translating, it becomes hard to tell what actually caused a broken outcome. Check field names, required settings, helper text, option values, conditional logic, error messages, confirmations, and notifications. Once that is stable, send the form for translation.

Pay special attention to the difference between labels and values in fields with choices. The visitor sees the label, while form logic, exports, or integrations often rely on the value. If you translate a value that is used in a condition or passed to an external service, the condition may stop matching. For forms with conditional logic, it is safer to set clear source-language values in advance and not treat them as ordinary translatable text.

The Page Where the Form Is Embedded

WPML explicitly reminds you that to see the form in another language when switching languages, you must translate the page containing the form. This is one of the most common omissions. An administrator translates the form itself, opens the front-end page, switches languages, and expects to see the result. But if the page has not been translated or linked to the source page, WPML may not show the correct language version of the page, which means the form check will be misleading.

Quick takeaway: before installation, prepare not only the plugins but also a test page. The ideal verification setup looks like this: the source page contains the form, the translated page is linked through WPML, the same Gravity Forms object appears on both pages, and the language is switched through the site's language switcher.

Installation and Initial Verification in the WordPress Admin Area

Installation depends on how you normally add commercial WPML components. Inside WordPress, that may be the Commercial tab in the plugin installer, while manual installation means uploading a ZIP archive through Plugins > Add New Plugin. In either case, after activation you should verify more than the plugin list. Also check that Gravity Forms appears in the Translation Dashboard.

Do not begin with a large production form. Create or choose a short test form instead: name, email, a topic dropdown, a consent checkbox, a simple confirmation, and one notification. That set covers the main text types without turning the first check into a large project. Once the test form works, move on to the real one.

Basic Sequence

1. Activate WPML and configure the site languages in the WPML setup wizard.
2. Activate WPML String Translation, Gravity Forms, and Gravity Forms Multilingual.
3. Open WPML > Translation Dashboard and find the Gravity Forms section.
4. Select one test form and send it for translation.
5. Open WPML > Translations, complete the translation, or review the automatic result.
6. Translate the page where the form is embedded and verify it on the front end.

After activation, you do not need to look for a large standalone settings page just for Gravity Forms Multilingual. Most of the work happens through WPML: Translation Dashboard, Translations, Advanced Translation Editor, and String Translation. That matters for the team. If an editor looks for form translation only inside the Forms menu, they may conclude that the plugin "didn't add anything." In reality, it adds the form as a translatable object inside the WPML system.

Initial Check After Activation

Open the test form in the source language and make sure it displays normally. Then send it for translation and check whether the editor includes not only the fields, but also the confirmation and notification. If the Advanced Translation Editor shows only part of the form, do not keep going blindly. Go back to the form, make a small safe change, save the form, and send it for translation again. That kind of re-registration often helps WPML detect updated form strings.

If the form is embedded through a shortcode, check the parameters. For example, title="false", description="false", ajax="true", and similar values are technical display settings. They must not be translated as regular text. In one WPML support case, a missing translation on the front end was caused by translating the false value inside the shortcode for another language. That is a good example of why form translation and page translation need to be verified together.

Translating the Form Through Translation Dashboard and Advanced Translation Editor

The main workflow revolves around two WPML screens. In Translation Dashboard, you choose the form and languages. In Translations, you open the job for review or manual translation. The Advanced Translation Editor shows form elements as translatable segments. For editors, that is much easier than hunting for each string in different areas of Gravity Forms.

The workflow is straightforward: the form remains the source object, WPML creates a translation package, and Gravity Forms Multilingual sends the form's text-based elements into that package. When a visitor opens the page in another language, WPML inserts the translated strings into the form. That is exactly why you cannot verify the outcome only in the admin area. You need to open the front-end page in the target language, fill out the form, and review the full user journey.

What You Must Translate

In a short contact form, everything seems obvious: name, email, message, submit button, success message. But real forms contain many hidden or semi-hidden elements that also affect quality. If the visitor sees a Spanish page but gets a German email or an English error message, confidence in the form drops. That is why the translation checklist needs to be broader than just "visible fields."

• The form title and description, if they are shown on the page.
• Field labels and the sub-labels of compound fields.
• Choice labels in Radio Buttons, Checkboxes, Drop Down, and similar fields.
• Placeholder text, if the form uses placeholders instead of visible labels.
• Consent text, the policy link, and helper notes beneath the field.
• Confirmations shown after a successful submission.
• Notification subject lines and bodies, if they vary by language.

How Not to Break Conditional Logic During Translation

Gravity Forms conditional logic shows or hides fields based on rules. Those rules compare the selected value to an expected value. If the translator changes not only the user-facing label but also the technical value, the rule may stop matching. The usual symptom looks like this: in the source language, an extra block appears, but in the translated version it does not, even though the user chooses the same logical option.

The practical rule is this: translate the human-readable labels, but treat the technical values behind conditions, calculations, exports, and integrations with care. If the editor shows pairs that look like label/value, verify which part is actually used by the logic. For a complex form, it helps to create a small map: field, choices, where the value is used, and which notifications or confirmations depend on that choice.

Check for a Multi-Choice Field

1. Open the source form and note the choices that trigger conditional fields.
2. Check whether the field uses a separate value distinct from the label shown to the visitor.
3. In the translation, change the label, but do not change the internal value without a reason.
4. After translation, open the page in every language and select each option that should reveal an additional block.
5. If the block does not appear, check the translated values, page cache, and JavaScript errors in the browser.

Automatic Translation and Human Review

WPML offers different ways to translate: automatically, by yourself, through a translator user, or through a service. For forms, automatic translation is especially convenient on the first pass because there may be many fields. But a form is not a regular article. Short labels, legal consent text, choice labels, and emails all require careful editorial review.

During review, look beyond grammar. Check whether the tone fits the market, whether the submit button is clear, whether a phrase became too long for a narrow field, whether merge tags were preserved, and whether email addresses, technical values, and shortcodes were left untouched. Ideally, the translator sees not only the list of strings, but also the front-end page with the form. That way, they understand where the string appears and why a literal translation may be wrong.

Result check: a completed form translation is not the same as a finished multilingual workflow. It is only ready after a test submission in every language, review of the confirmation, verification of the email, and checking the entry in Entries.

The Form Page, Shortcode, and Language Switcher

The form does not exist in isolation. The visitor lands on a page, reads the context, fills in the fields, and submits data. That makes the "page + form + language" combination more important than translating fields by themselves. WPML displays the translated form correctly when the current page has a language version and the form is embedded in a standard way: through the Gravity Forms block, the insert button, a shortcode, or another supported output method.

If the form is embedded through a block, life is easier for the content manager because the visual editor shows which form is selected. If a shortcode is used, you need to watch the parameters carefully. Gravity Forms documents parameters such as id, title, description, ajax, tabindex, field_values, and theme. For multilingual use, it is especially important not to translate technical values and not to change the form id between languages without a clear reason.

A Safe Rule for Shortcodes

On translated pages, it is best to treat the shortcode as code. The visible text around it gets translated, but the parameters stay in their original form unless you intentionally use different values by language and fully understand the consequences. For example, title="false" must not become a localized word. id="3" must point to a real form. If the same form is used in every language, the id usually stays the same.

[gravityform id="3" title="false" description="false" ajax="true"]

This example should not be copied blindly. It illustrates the principle: shortcode parameters are display settings. If the form does not appear in the translation, first check the id, the presence of the form, the translated page, and the parameters, and only then start looking for a problem in the field translation.

What to Do About AJAX Submission and Cache

The ajax="true" parameter can improve the user experience because the form submits without a full page reload. But on a multilingual site, that adds another layer of complexity. Cache, JavaScript optimization, deferred script loading, and language-specific URLs can all affect submission behavior. If the form works without AJAX but stops showing the correct confirmation or becomes unstable with AJAX enabled, first check the browser console for errors and review cache exclusions for the form page.

You do not need to disable every optimization across the site in advance. A more reliable approach is to isolate the issue: test the page without script combining and deferred loading, exclude the specific form URL from aggressive caching, clear the WPML cache and the page cache, and then re-enable settings one at a time. That gives you evidence instead of a pile of random toggles.

Notifications, Confirmations, and Submission Entries

Notifications and confirmations are the most underestimated part of form translation. The fields may look correct, but after submission the user gets a message in another language, and the administrator sees an email containing source-language choice labels. The official Gravity Forms documentation distinguishes between confirmations and notifications: the confirmation is shown to the user immediately after a successful submission, while the notification is usually sent by email. Through the integration, WPML makes those text-based elements available for translation, but the final check is still your responsibility.

Post-Submission Confirmation

The confirmation may be a simple message, a page redirect, or a URL redirect. On a multilingual site, it is better to avoid hardcoded links to a thank-you page in the source language. If you use a page redirect, make sure the thank-you page has a translated version and that the form confirmation points to the correct one. If you use a text confirmation, verify it in the Advanced Translation Editor along with the rest of the form content.

A special trap is conditional confirmations. Gravity Forms can show different confirmations based on conditions, but the default confirmation always remains the fallback. If the condition does not fire in the translation, the user will see the default message. That is why forms with multiple outcomes need more than a single successful submission test. You need to test every important path, such as a service request, a support request, and a newsletter signup.

Emails to the Administrator and the User

Notifications may include merge tags, the {all_fields} field, conditional logic, and recipient routing. The email translation needs to preserve the technical inserts while localizing the human-readable text around them. If the email arrives in the wrong language, start with a simple test: submit the form on a test page and check the page language, the administrator user's language, the form translation, and the notification translation. In WPML support cases, one common recommendation is to test behavior in a minimal environment: only the required WPML components, Gravity Forms, Gravity Forms Multilingual, and a default WordPress theme.

For sales or support teams, it can be useful to add an explicit line showing the submission language in the notification. You do not need to translate the entry itself. It is enough to see that the user submitted the form from a Spanish, German, or French page. That helps route the request to the right team member and quickly understand the context.

Entries Do Not Become Translations

WPML support discussions make one limitation clear: the plugin translates the form, but it does not create native translations of the content inside submissions that have already been received. If a user enters a message in Italian, the entry will remain in Italian. That is expected. A submission is user input, not interface text from the form. If the business needs to group submissions by language, it is better to add a hidden field or another internal language marker than to expect WPML to translate submission content during export.

Practical Example: Translating a Service Request Form

Let us walk through a realistic use case for an agency or service company website. There is a "Request a Quote" form in the source language. The user selects a project type, enters a name, email, and comment, agrees to the policy, and receives a confirmation. The administrator receives a notification that includes the request type. The goal is for the same form to work in Russian, German, and Spanish without creating three separate copies.

Goal

We want a single manageable Gravity Forms object that shows visitors labels in the language of the current page, stores submissions in one shared Entries table, sends a clear notification, and preserves conditional logic based on project type. The outcome should be verified at the level of the full user journey, not just by seeing that the translation is filled in.

Preparation

Before translation, the source form should include the following:

• Name and email fields with clear labels and required-field messages.
• A Project Type field with the options Website, Support, Consulting.
• A conditional block with extra questions for the Website option.
• Consent text with a link to the privacy policy.
• A post-submission confirmation with a neutral message and a link to the next page if needed.
• An administrator notification with a subject line that includes the project type and the request language.

If the choice field uses a separate values column, keep the values stable and translate the labels. That allows the rule to keep matching the expected value while visitors still see the translated text. If the values and labels are the same, test the conditional logic especially carefully.

Translation Steps

1. Open WPML > Translation Dashboard and find the Gravity Forms section.
2. Select the request form and the target languages.
3. Send the form for automatic translation or assign it for manual translation.
4. Open the job in WPML > Translations and review every form segment.
5. Save the translation only after checking labels, choices, consent text, the confirmation, and the notification.
6. Translate the page where the form is embedded and confirm that the shortcode or block points to the same form.
7. Open the front end in each language through the language switcher and submit the form using test data.

What You Should See

On the translated page, the user sees localized field labels and choice options. When the project type is selected, the correct conditional block appears. After submission, the confirmation is shown in the page language. The notification arrives with the correct subject line, and the entry appears in Gravity Forms Entries. If a hidden language field has been added, the entry can be filtered quickly by market.

A Note on Legal Text

Consent to data processing and the policy link should not be translated "by feel" without legal review. If the privacy policy has separate pages for each language, the link inside the consent text should point to the matching page. If that page does not yet exist, it is better not to publish the form in that language until the legal text is ready.

Quick takeaway: a successful Gravity Forms Multilingual setup is not just a set of translated labels. It is a verified chain where the page, form, condition, confirmation, email, and submission entry all work together.

How to Verify the Result After Setup

Verification should be repeatable. If you only opened the page and saw translated fields, that is just the first layer. For a form, what matters is submission behavior, rules, notifications, stored entries, integrations, and what happens after the source form changes. That is why it helps to create a short test workflow and run it every time after translation or after updating the plugin stack.

Front-End Check

Open the source page and every language version as a normal visitor. Use the language switcher rather than a direct admin link, because that is how real users behave. Check whether the form disappears when switching languages, whether source-language text appears on the translated page, whether styling breaks, and whether old placeholders remain.

If the site uses caching, test in a private window and after clearing the cache. On pages with forms, cache must be configured carefully. The page itself may be cached, but the form scripts, field validation, and AJAX response must not break because of aggressive optimization. If you are unsure, compare behavior with caching disabled on a site copy.

Submission Check

1. Submit the form in the source language and save the result as your baseline.
2. Repeat the submission in every language with different choices selected.
3. Check the confirmation immediately after submission.
4. Check the email notification received by the administrator and, if configured, by the user.
5. Open Forms > Entries and compare the entry, the choice values, and the internal submission language marker.
6. If there is a CRM, spreadsheet, Zapier workflow, or another external handler, make sure it received the expected fields.

Check After Changing the Form

When you add a field, change an option, or edit a notification in the source form, the translation may become outdated. In WPML, those jobs typically need an update. Do not wait for user complaints. After changing the form, immediately open Translation Dashboard, send the form for an updated translation, and repeat the test submission.

Settings That Most Often Need Attention

Gravity Forms Multilingual does not have a long standalone panel full of toggles. Most of the configuration is split between WPML and the form itself. Because of that, it is more useful to think in terms of "which form touchpoints must be known to WPML, and what must not be translated" rather than "which options should I enable." That mindset gets you to a stable outcome faster.

Translation Dashboard as the Control Center

In Translation Dashboard, choose the form, the languages, and the translation method. If the form is large, automatic translation helps you produce a first pass quickly, but the editor still carries the final responsibility. Forms often contain short phrases with context the machine may miss: "Submit," "Other," "Business," "Message," "Consent," "Quote," and similar words shift meaning depending on the form.

It helps when the team agrees on a workflow: who creates the source form, who sends it for translation, who reviews legal text, who tests submission behavior, and who approves publishing. That keeps form translation from getting stuck between the developer, marketer, and translator.

String Translation for Missing Strings

Sometimes a string does not appear as a normal translation segment in the form or stays in the source language. In those cases, WPML offers String Translation and string search tools, including plugin or theme scanning. This is useful for placeholders, strings coming from settings, theme text surrounding the form, and certain strings that only appear after the page is rendered.

Do not leave heavy JavaScript string tracking enabled all the time without a reason. WPML documentation warns that this mode can put extra load on the server. Turn it on only to find a specific missing string, open the page where it appears, find and translate it, and then disable the mode again. That is much cleaner than leaving diagnostic scanning permanently enabled.

Glossary and Consistent Terminology

If the site serves multiple markets, the same terms should be translated consistently. That becomes especially visible in forms: service, project type, department, product name, consent text, request category. WPML supports glossary usage during translation, and it is worth using for terms where a mistake changes the meaning of the request. For example, "quote" in a service form may mean a pricing proposal rather than a citation. One inaccurate translation in a choice field can lead to confusing submissions.

Media Translation for Image Choices

The Gravity Forms Multilingual release notes mention support for translating images assigned to Image Choices through WPML Media Translation. That matters when a choice is represented not only by text, but also by an image. In that type of form, translation should account for the label, the value, and the image. If the image contains text or culturally specific meaning, each language may need its own image version.

For those forms, check more than the visible labels. Also review which choices appear in the Advanced Translation Editor. WPML errata pages have documented Image Choice and Multiple Choice issues in certain versions. So before launching a form with important choice-based behavior, review the current known issues page and the release notes. If the problem has already been fixed in your version, updating components is better than applying temporary edits to plugin files.

Conditional Logic, Field Values, and Integrations

The most important product-specific aspect of this setup is that translation must preserve both the form structure and the processing behavior. Visitors see localized text, but the server, the notification, the conditional block, and the integration often continue to rely on technical values. That is where Gravity Forms Multilingual differs from simply translating a page. It works with the form as an object where text and behavior are tightly connected.

Label and Value in Choice Fields

In a simple choice field, the label and value may be the same. For example, the user sees Support, and that same value is stored in the entry. But for a multilingual site, it is better to separate the readable label from the stable value. The visitor may see "Support," "Soporte," or another translation, while the integration still receives one stable value: support. That lowers the risk that the CRM, spreadsheet, or notification rule starts receiving inconsistent data because of translation.

If the form already exists and the values match the labels, do not change them on a live site without preparation. First, check where those values are used: conditional fields, confirmations, notifications, calculations, add-on feeds, exports, and external services. Then, on a site copy, configure stable values and run the translation workflow again.

Conditional Logic Across Multiple Languages

Gravity Forms applies conditional logic to fields, buttons, notifications, confirmations, and feeds. Gravity Forms documentation also describes several limitations: self-referencing rules are not supported, fields hidden by conditional logic are not saved on submission, special characters and HTML inside values may interfere with rules, and very large forms may run more slowly because the conditions are evaluated in the browser.

For a multilingual site, that leads to two practical conclusions. First, do not use long translated phrases as values if the logic depends on them. Second, for longer forms, test every language path through actual submission, not just visually. If a hidden field is missing from the saved entry, that may be standard conditional-logic behavior rather than a translation bug.

Zapier, CRM, and Spreadsheets

The WPML known issues page describes a case where, with the Gravity Forms Zapier Add-On and WPML together, some entry metadata was passed incorrectly in connected actions. In the workaround, WPML recommends scanning Gravity Forms in Theme and plugins localization and translating problematic fields consistently across languages. In practice, that is an important signal: if the form passes data onward, your verification must include the external service.

Do not stop once the submission appears in Entries. Open the destination system as well: CRM, Google Sheets, email platform, or ticket system. Check whether the language matches, whether internal fields came through, and whether payment status, user agent, entry id, and other metadata required by your workflow are still present. If the integration only works in the source language, temporarily simplify the form and rule out the effect of translated values.

Special Gravity Forms Fields and Language Files

Most simple forms can be translated without a separate strategy. A text field, email field, textarea, dropdown, consent checkbox, and post-submission message are straightforward for an editor. The complexity begins when a field carries not only text, but also its own behavior. In Gravity Forms, that includes compound fields, address fields, image-based choices, pricing fields, surveys, multi-page forms, file upload fields, and add-ons that change what happens after submission. Gravity Forms Multilingual helps pass the translatable parts into WPML, but the administrator still needs to understand exactly what should be checked.

A separate topic is the language files used by Gravity Forms itself. They translate the plugin's core system strings, not your custom form labels. For example, default messages, some country names, interface elements, and plugin localization may come from language files. Gravity Forms documents where those files are stored in the WordPress languages directory, while WPML String Translation can help find strings that did not appear in the normal form translation flow. In practice, these two layers should not be mixed: your custom form text is translated through the WPML translation job, while Gravity Forms system strings may depend on language files and String Translation.

Addresses, Countries, and Compound Labels

The Address field and similar compound fields may look like one element in the form editor, but inside they contain multiple parts: street address, city, region, ZIP code, country, and additional sub-labels. In WPML support cases, site owners have run into situations where country names in a regular dropdown were not translated as expected because the translations in Gravity Forms language files applied to the advanced Address field rather than to a custom country list in a standard Drop Down. The practical lesson is important: if you need a standard country list, check the built-in Address field first before creating your own dropdown with hundreds of choices.

If you still use your own country, city, or department list, plan time to translate the choices. Do not assume WPML will automatically understand that your list duplicates a standard Gravity Forms reference list. For a large list, verify how the strings appeared in Translation Dashboard or String Translation, and do not launch the form in a new language until the choices have at least been spot-checked on the front end.

Practical Check for a Compound Field

1. Create a test submission in the source language and save the entry.
2. Repeat the submission in the translation, filling out every part of the compound field.
3. Compare the labels on the front end, the entry in Entries, and the administrator email.
4. Check whether any sub-labels remain in the source language.
5. If the string is not found in the translation job, look for it in String Translation or the Gravity Forms language files.

Image Choice, Multiple Choice, and Image-Based Options

Image Choice and Multiple Choice fields are especially sensitive to the version combination you are using. The Gravity Forms Multilingual 1.8.3 release notes mention support for two new Gravity Forms 2.9 fields, along with the ability to translate images used in Image Choices through WPML Media Translation. That is useful when the user selects a service, product variation, package type, or image-based answer option through a picture. But those fields should not be tested like an ordinary text list.

For every image-based choice, verify four layers: the image, the label, the value, and the follow-up action. The image may contain text or culturally specific imagery. The label needs to be clear to the visitor. The value should stay stable if it is used in a condition, calculation, or integration. The follow-up action may be a field reveal, a calculation, an email, a thank-you page, or a CRM record. If even one layer goes unchecked, the form may look translated while still sending incorrect data.

Do not apply an old errata workaround just because you found it in search results. First, make sure the version and the symptom actually match your case. If the release has already fixed the issue, the correct move is to update the components and send the form for translation again. A temporary plugin-file edit may be useful as an emergency measure on a site copy, but it should not become a standard maintenance routine.

Pricing Fields, Multi-Currency, and Commercial Forms

If Gravity Forms is used not only for contact forms but also for requests with pricing, surcharges, product options, or WooCommerce Multilingual integration, translation affects a more critical workflow. A known WPML page describes a case where the Option Pricing field lost its price and currency on the front end when WooCommerce multi-currency was enabled. Even if that specific issue has already been fixed or does not affect your version, the risk category remains clear: forms involving pricing should be tested as commercial workflows, not like ordinary email forms.

Check the currency, number format, separators, final total, administrator notification, and submission entry. If the form creates an order, lead, or payment workflow through an add-on, test every currency and every language. Do not tell users that everything is compatible "by default" until you have seen the result on your own site. When money is involved, caution matters more than launch speed.

Surveys, Conversational Forms, and Multi-Page Workflows

Release 1.8.0 added support for Survey AddOn elements and Conversational Forms AddOn. That is good news for sites where the form is not just a short contact form, but a conversation, questionnaire, lead qualification flow, or audience research tool. But those are exactly the forms with more room for mistakes: page headings, navigation buttons, scale labels, field captions, validation messages, save-for-later text, and conditional transitions.

For a multi-step form, it is useful to test the translation as a visitor workflow. Open the first step, choose an option, move forward, go back, try a required field, save the form for later if that feature is used, and complete the submission. Compare the result in every language. If one step remains in the source language, do not patch it at random. Determine where the string comes from: the form itself, the add-on, the theme, a language file, or JavaScript.

How to Organize Team Work Around Form Translations

Technical setup solves only half of the problem. The other half is the process. On a small site, one administrator may be able to create the form, translate it, run a test submission, and publish it alone. On a working project, different people are usually involved: a developer owns the structure and integrations, an editor handles the text, a translator handles the language, legal reviews the consent text, marketing owns the funnel, and a manager handles submissions. If responsibility is not divided clearly, the form quickly turns into a place where "everything seems translated," but nobody has checked the full path.

Roles and Checkpoints

A good workflow starts with a form owner. This is the person who understands the business goal: what kind of submission is needed, who handles it, which fields are required, which languages matter, and what counts as a successful outcome. The technical administrator then builds the form in Gravity Forms and makes sure the structure is clear for translation. The translator works in WPML, and the tester or editor goes through the public form as a visitor.

This kind of table is not necessary for every microsite, but for forms involving leads, requests, and legal consent text, it saves time. If something breaks after an update, the team immediately knows who checks the structure, who refreshes the translation, who reviews the email, and who approves publishing.

Test Data for Submission Checks

Prepare a small set of test data for every language. Do not use real customer personal data. A placeholder name, a test email address, one selected option, and a short comment are enough. The main thing is that the tests are repeatable. For example, each language can use its own project type and comment. That makes it easy to see in Entries where the submission came from and which form path was tested.

If the form sends data to an external service, agree on a test marker: a dedicated field value, a special tag in the comment, or a test address. After the check, remove the test records wherever your internal site rules require it. Do not leave dozens of unclear submissions in the CRM, because a month later nobody will remember which ones were tests.

Change Documentation

Every form change should have a short record: what was changed, which languages were updated, who verified it, and what issues were found. This can live in a project task, internal wiki, or a regular document. For Gravity Forms Multilingual, it is especially useful to document fields whose values must not be translated and strings that live outside the main form translation, in String Translation instead.

As the site grows, this documentation becomes practical insurance. A new editor will see that support in a value must not be translated because email routing depends on it. A developer will see that the thank-you page has separate language versions. A translator will understand that a short button label must fit into a narrow layout. This is not bureaucracy. It is a way to keep the form working after several update cycles.

Performance, Safety, and Careful Improvements Without Editing the Plugin

A form on a multilingual site should be not only translated, but also usable. Translation often changes label length: German text may be longer than English, a Russian label may wrap differently, and a Spanish button may not fit into a narrow block. Safe improvements at the theme, custom CSS, and testing-process level can help here. There is no need to edit the WordPress core, Gravity Forms, or Gravity Forms Multilingual.

CSS for Long Form Translations

If translated field labels become too long and start breaking the layout, start with CSS. Add a small snippet in Appearance > Customize > Additional CSS or in a child theme. It does not interfere with form logic, it does not change submission data, and it is easy to roll back by removing it.

/* Helps long Gravity Forms translations wrap cleanly */
.gform_wrapper .gfield_label,
.gform_wrapper .gform-field-label {
  overflow-wrap: anywhere;
  line-height: 1.35;
}

html:lang(de) .gform_wrapper .gfield_label,
html:lang(es) .gform_wrapper .gfield_label,
html:lang(ru) .gform_wrapper .gfield_label {
  max-width: 100%;
}

.gform_wrapper .gchoice label {
  overflow-wrap: anywhere;
}

The check is simple: open the form in every language, zoom the browser in, inspect the mobile view, and make sure the label does not overlap the field, checkbox, or button. If the theme uses its own form classes, the CSS selectors may need refinement. Rolling back is straightforward: remove the snippet and clear the cache.

Hidden Field for Submission Language

If the team needs to filter submissions by language, it is safer to add a Hidden field in Gravity Forms than to try translating the Entries themselves. The value can often be filled using standard page parameters or another small, proven site mechanism. Without writing code, it is often enough to pass a parameter in the shortcode or use dynamic field population if that is already configured in Gravity Forms.

For example, the page with the form can use a query string or different field values on each language version of the page. The key is not to mix this with translation of visible labels. The hidden language field is meant for internal routing: who should reply to the user, which submissions the manager should see, and which data should be sent to the CRM. The visitor does not need to see it.

Cache and Script Optimization

Forms using conditional logic and AJAX depend on JavaScript. If an optimizer combines, defers, or relocates scripts, the form may look fine but fail to submit, fail to show conditional fields, or fail to refresh the confirmation. For a page with an important form, it helps to create a dedicated rule: exclude the form URL or Gravity Forms scripts from aggressive deferral, then test every language version.

You do not need to disable all site caching forever. The goal is targeted compatibility. First, confirm the symptom on a site copy. Then exclude the smallest possible piece and rerun the test. If the problem disappears, document the rule for the team so the next administrator does not accidentally bring the conflict back while cleaning up optimization settings.

How to Update the Form and Its Translations Without Losing Sync

A form rarely stays unchanged forever. You may add a new request type, update consent text, refine notifications, connect a CRM, or add a new language. Gravity Forms Multilingual is most useful when those updates are handled with discipline: first the source form, then the translation, then the verification. If that order is broken, it is easy to end up with a form where some strings are old, some are new, and the conditional logic sends users down an unpredictable path.

Order When Changing a Field

If you only need to change a label or helper note, that is the simplest kind of update. Edit the source form, save it, send it for a translation update, and verify the public page. If you change a value, a choice, required status, or a condition, the change becomes riskier. Document where that field is used and test every dependent path. For forms with integrations, always verify the external service as well.

Order When Adding a New Language

A new site language means more than just one extra column in WPML. You need to translate the page, the form, the confirmation, the notification, related thank-you pages, the privacy policy, the user email, and possibly the surrounding theme strings near the form. When a language is added in a rush, the form often becomes "partially translated": the user sees localized fields, but after submission lands on the source-language thank-you page.

Order When Updating Plugins

After updating Gravity Forms, WPML, and Gravity Forms Multilingual, review forms that use new or complex field types. The release notes show that compatibility can affect Multiple Choice, Image Choice, block styles, Review Form, option pricing, and checkbox values. That is not a reason to postpone updates. It is a reason to include forms in the site's regression checks.

Practical rule: after every meaningful form change, run one short test in every language: open the page, select a conditional option, submit the form, and verify the confirmation, email, and stored entry.

Videos and Visual Help for the Product

During review, no single clearly reliable YouTube video focused specifically on Gravity Forms Multilingual could be confirmed. The official documentation includes visual steps and a "See how to do this" video link, but the available results were not strong enough to confidently embed a dedicated YouTube block as a source that applies fully to this product without blending it into general WPML setup material. That is why no video is embedded in this article.

Instead of relying on a random video, it is more useful to work from official WPML and Gravity Forms screenshots, along with the custom verification visuals in this guide. They show exactly what matters to users in this specific workflow: where the form enters translation, how the submission moves through to the notification, where to look for errors, and what to test after updates.

When Gravity Forms Multilingual Is the Right Choice

Gravity Forms Multilingual is worth using when you already have Gravity Forms, the site is translated through WPML, and forms are part of a real user journey. The plugin helps you maintain one form structure, translate its text elements through WPML, and verify the result together with the page, notifications, and confirmations. That is especially valuable for sites with multiple languages, frequent form changes, and team-based translation workflows.

Before launching on a live site, review WPML requirements, update the related components together, create a test form, translate the page containing the form, and run test submissions in every language. If the result is stable, move on to the real forms. If you are ready to try it on your own site, you can download Gravity Forms Multilingual near the file block and repeat the setup first on a site copy.

The main selection criterion is simple: if you need controlled Gravity Forms translation inside the WPML ecosystem, this bridge handles the job better than manually duplicating forms. If the site runs on a different multilingual solution or the forms must differ fundamentally between markets, compare the working model first and only then change the structure. A good multilingual form is not just translated labels, but a clear user journey from the page to the confirmation and the email.