How to Translate Contact Form 7 in WordPress – Form-Tags, Messages, Mail Templates

Before You Start

Install and activate these plugins:

• Contact Form 7.
• WPML and WPML String Translation.
• WPML Multilingual for CF7 (the add-on this page covers).

Build the form in Contact Form 7 in your site’s source language (every form-tag, the Mail and Mail (2) templates, every entry on the Messages tab, and any Additional Settings) before sending the form for translation. You can edit the form later and re-send it for translation if anything changes.

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 Contact 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 template, Mail and Mail (2), and the Messages tab 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

Contact Form 7 sits inside a page or post through the [contact-form-7] shortcode, usually generated by the Contact admin screen as [contact-form-7 id="123" title="My Form"]. The multilingual insertion rule:

Use the same 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 shortcode on the source-language page.
4. Translate the page through WPML > Translations > Dashboard the same way you’d translate any other page. The shortcode is preserved on the translated page.
5. When a visitor opens the translated page, WPML Multilingual for CF7 serves the form in the visitor’s language automatically – same shortcode, translated content.

You don’t need a different form ID 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.

ID-based and title-based shortcodes both work. [contact-form-7 id="123" title="Contact form 1"] works multilingually out of the box. [contact-form-7 title="Contact form 1"] (title only, no ID) also resolves to the right language. Title-only resolution shipped in 1.1.0 (June 2021). Both forms are safe.

The exception – when you genuinely want different forms per language. If you need structurally different forms per language (different form-tags, different Mail templates, different Messages tab content), build separate Contact Form 7 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.

Form-Tag Labels and Visitor-Facing Strings

Every form-tag’s visitor-facing content translates: labels (the text outside the bracketed tag), button labels (the value in [submit "Send"]), placeholders set via the placeholder option, and the option values inside [checkbox], [radio], and [select] tags.

The form-tag type and name don’t translate. They’re identifiers. The form-tag values (the visitor-facing choices) do translate. Example:

[select your-country "China" "India" "San Marino"]

In the French translation, "China" becomes "Chine" while your-country (the form-tag name) and select (the type) stay identical. Mail-tag substitution still works because the translation preserves the position of each value.

Pipe-Separated Values – Translate the Label, Keep the Value Stable

Pipe syntax lets you decouple the visitor-facing label from the value sent in the email:

[select your-country
  "Chinese|CN"
  "Indian|IN"
  "Sammarinese|SM"]

When you translate this form, only the labels (Chinese, Indian, Sammarinese) translate. The values (CN, IN, SM) stay canonical. A French visitor sees Chinois, Indien, Saint-Marinais; the email body and any backend handler still receive CN, IN, SM. Use pipe syntax wherever you need the submitted value to stay stable across languages: CRM mappings, payment SKUs, geographic codes.

Acceptance and Quiz Tags

The Acceptance checkbox carries the consent text and usually one or more embedded links to privacy and terms pages. Translate the text as a single row in the translation job; for the link targets, edit the translated row to point to per-language privacy and terms pages.

Quiz tags translate both question and answer. Use the pipe syntax for quiz answers so the accepted-answer logic stays predictable across languages:

[quiz captcha
  "1+1=?|2"
  "2+3=?|5"]

The Messages Tab

Contact Form 7’s Messages tab carries ~16 editable validation strings – the ones visitors see on submission and on error. Every one translates in the same job:

• Thank you for your message. It has been sent.
• One or more fields have an error. Please check and try again.
• There was an error trying to send your message. Please try again later.
• This field is required.
• This e-mail address is invalid.
• The telephone number is invalid.
• The URL is invalid.
• The number is smaller than the minimum allowed.
• The number is larger than the maximum allowed.
• The date format is incorrect.
• The file is too big.
• The file is not supported.
• The Acceptance checkbox is required.
• The answer to the quiz is incorrect.
• (plus the remaining default messages CF7 ships).

If your Messages tab uses mail-tags to interpolate input (Thanks [your-name], your message has been sent!), the mail-tag still resolves correctly after translation.

Mail and Mail (2)

Contact Form 7’s two outgoing email templates, Mail (admin notification) and Mail (2) (optional reply or autoresponder to the visitor), translate independently. To, From, Subject, Additional headers, Message body, and the File attachments descriptions all sit in the translation job. Mail-tags inside the translated bodies ([your-name], [your-message], [your-email]) resolve correctly.

For Mail (2), the visitor-facing autoresponder body is where translation matters most. That’s the message that lands in the visitor’s inbox. Send a test submission from a translated page and confirm the autoresponder arrives in the visitor’s language.

Submission Integrations

Contact Form 7 has a small but important set of integrations. Each one preserves the visitor’s language when translation is configured:

• Flamingo. The Contact Form 7 author’s submission-management add-on. Submissions land in Contact > Inbound Messages with the translated subject and body intact.
• Constant Contact. CF7’s official email-marketing integration. Visitor input flows through to your Constant Contact lists in the visitor’s language.
• Stripe. Contact Form 7’s [stripe] form-tag fields and the receipt-message text both appear in the translation job.
• Akismet. Spam-protection messaging translates through WPML String Translation (not the form-translation job).
• reCAPTCHA. The visitor-facing error message translates through WPML String Translation.

Common Pitfalls

• Acceptance with embedded link points to the wrong language’s privacy page. Edit the Acceptance translation in the Advanced Translation Editor and set per-language link targets.
• Shortcode hash mismatch on CF7 6.0+. Resolved in WPML Multilingual for CF7 1.3.2 (Nov 2024). Upgrade if you see this.
• The Messages tab translations don’t appear. Confirm WPML String Translation is active and that the form was re-sent for translation after editing the Messages tab.
• Mail-tags inside translations resolve to empty strings. Check that the form-tag name in the mail-tag (e.g., [your-name]) matches a form-tag in the form. The translation never breaks mail-tag resolution, but renaming a form-tag after translation will.