Skip to content

WordPress systems / Case 10

English and Spanish location forms with one predictable lead-routing path

Localized pages needed the correct language-specific form and content defaults while leads still arrived through the same dependable business workflow.

WordPressPolylangGravity FormsZapierSalesforce

What this solved for the business or user

A visitor on a Spanish page should see a Spanish form and labels without the marketing team manually rebuilding the page. When the form is submitted, the lead still needs to reach the same downstream sales process with the correct page and language context.

What was happening

The location template served English and Spanish pages. Each language could use a different Gravity Form, while older fields sometimes still contained English defaults. The forms also fed an external workflow through Zapier into Salesforce, so choosing the wrong form or losing page context affected more than the visible page.

Why the obvious solution was not enough

Language-specific presentation and business lead routing had to be separated. The template needed reliable defaults when an editor did not explicitly configure a shortcode, while avoiding hard-coded assumptions that made every future form change a code deployment.

How the solution works

  1. Detect the page language first and resolve the appropriate default form ID for that locale.
  2. Allow an ACF shortcode override when a page needs a different form, but build the Gravity Forms shortcode from the configured ID when no override exists.
  3. Keep AJAX behavior consistent so changing language does not create a completely different submission experience.
  4. Translate known legacy English defaults only when the page language is Spanish, instead of changing editor-authored values indiscriminately.
  5. Carry page and language context into the form submission so the downstream Zapier and Salesforce workflow can identify where the inquiry originated.
  6. Test the visible confirmation and the downstream lead record. A successful browser message is not enough if the integration silently fails after submission.
Locale-aware Gravity Forms fallback
$default_form_id = $is_spanish ? 18 : 17;
$form_id = get_field('location_hero_form_id', $page_id) ?: $default_form_id;
$shortcode = get_field('location_hero_form_shortcode', $page_id);

if (!$shortcode && $form_id) {
    $shortcode = '[gravityform id="' . absint($form_id) . '" title="false" description="false" ajax="true"]';
}

What should be verified before shipping

  • Open equivalent English and Spanish locations and confirm the expected form and labels appear.
  • Test a page with an explicit form override and another page using only the language default.
  • Submit both languages and verify the browser confirmation, Zapier run, and Salesforce record.
  • Confirm page URL, location, and language context survive the handoff where those values are needed downstream.
  • Test legacy English defaults on a Spanish page and confirm only recognized fallback values are translated automatically.

What changed

Editors gained language-aware defaults without losing the ability to override individual pages, and lead submissions remained connected to the same external workflow instead of becoming separate one-off integrations.

Reusable lesson

Localize the presentation layer, but keep the integration contract stable. Language should change what the visitor sees without making lead routing unpredictable.

Official documentation and standards