A translated registration form does not mean every resulting email should use the visitor's language. Diagnose the administrator notification and the registrant message separately. The browser confirmation is another output, and seeing the correct confirmation does not verify either email.
Check the integration behavior first
The Gravity Forms Multilingual 5.2.0 release fixes the administrator's New User Registration email language while preserving the registrant's own language. The version was released October 21, 2026. Verify supported WPML components together instead of updating only one shared integration component.
This release note concerns the User Registration path. It is not a promise that every custom Gravity Forms notification, SMTP template, or third-party welcome email chooses language in the same way. Identify which component generated the actual message before changing translation settings.
Identify the message by its recipient and purpose
Collect the subject, intended recipient role, test entry ID, form ID, and send time using controlled staging addresses. Do not share activation links, reset links, credentials, or real registrant details in a public support ticket. A screenshot of the subject alone may be ambiguous when several plugins send similar welcome messages.
Map the messages you expect from one synthetic registration. Include the administrator registration notice, the registrant notice, and any explicitly configured custom notification. If two components send the same welcome message, investigate that duplication before assuming one of them is a mistranslation.
One registration has separate administrator and registrant message paths. A translated confirmation in the browser is a third result. Explanatory diagram.
Run a crossed-language test
On isolated staging, choose different languages for the administrator context and the public registration form. For example, use English for the administrator and French for the test registrant. Those choices are an illustrative fixture, not a required site configuration.
- Record the administrator's relevant language preference and the form's public language URL.
- Register a synthetic account through that translated form using a mailbox you control.
- Open the saved entry and identify the registration action that ran.
- Inspect the administrator message and registrant message separately.
- Repeat with a second public language while keeping the administrator context fixed.
The useful assertion is that changing the public language changes the registrant's intended message without unexpectedly changing the administrator message. Avoid making both languages identical for every test: that can hide the very routing error you are trying to find.
Record whether a message is missing, in the wrong language, partly translated, or duplicated. Those are different outcomes. A delivery failure requires mail-path investigation; a received message with default-language wording requires template or language-context investigation.
Trace partial translations rather than replacing everything
Compare the subject, body, button label, and destination link. Identify whether the unexpected text belongs to the integration's generated message or to a custom notification. A correct translated subject with an untranslated custom paragraph does not justify replacing every registration template.
Check the destination of any permitted test-account action without exposing its token. A translated email that sends the user to an inaccessible page still fails the user journey. Do not turn off activation or broaden registration permissions to make a language test easier.
If the visible browser receipt is wrong as well, use the separate translated conditional-confirmation diagnostic. Keep its branch-selection evidence separate from email delivery and recipient language. One form submission can succeed in one output and fail in another.
Update and validate the whole registration journey
Install the compatible supported components on staging, then repeat the same crossed-language registrations. Keep the recipient roles, notification configuration, and form choices constant so the comparison remains meaningful. Isolate CRM, mailing-list, and other external actions to avoid creating real contacts during the test.
Before production release, confirm that the account has only its intended role, the expected messages arrive once, their language matches each recipient, and the approved follow-up route works. Preserve a sanitized message map with component versions and test timestamps. HandL WP can trace multilingual registration behavior when generated messages and custom notifications overlap. Do not send production passwords or private activation URLs with that handoff.
Sources reviewed November 1, 2026. Examples and diagrams are diagnostic aids, not customer test results.