When a Gravity Forms confirmation works in the source language but falls back to the default message in a translation, compare the same stored answer across languages before rewriting the form's rules. The integration version matters as well as the translated wording.
Check registration emails separately from the browser receipt
A correct translated confirmation verifies the selected browser response, not the administrator or registrant email. For User Registration, compare recipient roles and language independently using the registration email language diagnostic.
Use different administrator and registrant languages in the staging fixture so an incorrect shared language cannot pass unnoticed. Keep activation links and credentials out of screenshots. Do not alter working confirmation rules simply because an independently generated email uses the wrong template or language context.
Check the relevant WPML fix
Gravity Forms Multilingual 5.2.0, released October 21, 2026, fixes translated forms showing a default confirmation instead of the appropriate conditional one. Its release notes also explain the coordinated WPML component update. Check the supported versions of the installed integration and WPML components together.
This does not mean every unexpected confirmation is that bug. An overlapping rule, a changed choice value, a different form embed, or a wrong redirect can produce a similar complaint. Establish whether the problem is specific to the translated path before assigning a cause.
Make the failing submission reproducible
On an isolated test site, choose one form with two clear branches, such as Sales and Support. Use controlled contact details and keep outbound customer notifications or CRM writes isolated. Record the form ID, public page, language, AJAX setting, and exact choice submitted.
Give the confirmations distinct administrative names. A translated sentence may look similar enough that the selected branch is unclear. A short, harmless staging marker in each message helps distinguish the Sales confirmation from the Default receipt without relying on screenshots alone.
Do not put an email address or customer name into a redirect URL for this test. URLs can end up in analytics and logs. Use a non-personal test marker only when needed, and remove it before publishing the configuration.
Compare meaning, stored value, and result
Submit the Sales choice in the source language and then the equivalent translated choice. Inspect the saved entries. The translated label is what the visitor sees; the stored choice value is what the rule may evaluate. Write both down rather than assuming they are identical.
| Test |
Expected result |
Evidence |
| Source language, Sales value |
Sales branch |
Entry value and confirmation marker |
| Translated language, same meaning |
Translated Sales branch |
Stored value, language, marker |
| Translated Support choice |
Support branch |
Same three checks |
| Allowed unmatched input |
Defined fallback |
Default marker, without false completion claims |
If source-language submissions also fail, start with the general confirmation branch audit. It covers mutually exclusive rules and all-versus-any conditions. That is a different task from verifying that a correct branch survives translation.
Four pieces of evidence that distinguish a translated confirmation failure from an incorrect rule. Synthetic explanatory visual.
Separate branch selection from a bad destination
A correct confirmation can still send the visitor to the wrong language page. First identify the selected confirmation, then inspect its final destination. Record redirects and the eventual URL. A destination that becomes a 404 or switches language should not be reported simply as a default-confirmation failure.
For text confirmations, check that translated content actually belongs to the selected branch. For redirects, confirm that the destination is a published, accessible page in the intended language. Compare the same desktop and mobile embed when the form appears in a popup or builder template.
Update and rerun the small matrix
Take a recoverable staging backup and install compatible WPML components from their official distribution. Keep unrelated form edits out of that test so you can tell whether the integration update changes the result. Repeat the same four submissions and preserve the before-and-after branch record.
Do not replace all conditional confirmations with the default to silence the symptom. That may remove important sales, support, or consent-specific acknowledgements. Also avoid counting every test submission as a genuine business conversion in production reporting.
Before release, verify one complete permitted journey in each supported language, including the displayed receipt and any approved sandbox destination. Get help with multilingual form routing if the stored answer, branch marker, and destination still disagree. Supply sanitized evidence and component versions rather than a production entry containing personal information.
Reference and review date
Primary technical reference. Sources checked October 30, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.
Editorial update November 1, 2026: diagnostic distinctions and related guidance reviewed. Existing publication date and illustrative assets retained.