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.
Plain-English summary
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.
01 / Real situation
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.
02 / Constraint
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.
03 / Implementation
How the solution works
- Detect the page language first and resolve the appropriate default form ID for that locale.
- 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.
- Keep AJAX behavior consistent so changing language does not create a completely different submission experience.
- Translate known legacy English defaults only when the page language is Spanish, instead of changing editor-authored values indiscriminately.
- Carry page and language context into the form submission so the downstream Zapier and Salesforce workflow can identify where the inquiry originated.
- Test the visible confirmation and the downstream lead record. A successful browser message is not enough if the integration silently fails after submission.
$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"]';
}04 / Release checks
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.
05 / Result
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 lessonLocalize the presentation layer, but keep the integration contract stable. Language should change what the visitor sees without making lead routing unpredictable.
References
