Multilingual forms (WPML / TranslatePress / Polylang)

When you translate a form for a multilingual site, each language version is technically a separate form with its own internal ID. AFI sees them as distinct forms. The rule of thumb: create one AFI integration per language.

Why this happens

• WPML duplicates the form on translation, giving it a new ID.
• TranslatePress translates content via the post-content layer, but for form plugins that maintain their own database tables (Forminator, Fluent Forms), it creates parallel records.
• Polylang follows the WPML model: a translated form is a new entity in the form plugin’s eyes.

Recommended setup

1. Build the form in your primary language and configure its AFI integration first.
2. Translate the form. Note the new form ID (visible in the form plugin’s editor).
3. Duplicate the AFI integration: AFI > Integrations > [your integration] > Duplicate.
4. On the duplicate, change the Form dropdown to the translated form. Save.
5. Optionally, change the integration’s title to include the language code so you can recognise it later.
6. Repeat for each language.

Field-mapping notes

• Field keys typically stay the same across translations — only labels change. You usually don’t need to re-map fields, just re-select the translated form.
• Dropdown / radio values may be translated too. If your conditional logic references those values, you’ll need parallel rules per language (or a hidden form field with a fixed non-translated value to key on).

Conditional Logic and translations

If your rules check against a value the translator localised (e.g. Yes vs Sí), the rule will only match in one language. Two options:

• Add parallel rules per language using Any logic — match Yes or Sí or Oui.
• Use a hidden form field that holds a fixed, untranslated value (en / es / fr), and key your rules off that.

Related

• Reading the Log
• Smart Tags & Field Mapping
• Settings & Administration
• Conditional Logic isn’t firing