Statamic Easy Forms Laravel Package

Product Decisions This Supports

• Multilingual / multisite rollout: localize_submissions (env EASY_FORMS_LOCALIZE_SUBMISSIONS) turns per-page-language validation and reCAPTCHA error messaging into a config toggle rather than a custom build. This directly supports roadmap items for EU/APAC market expansion, localized landing pages, and per-locale campaign sites without forking the form layer.
• Build vs. buy on forms: The package now covers rendering, validation, spam protection, and localized error copy. That removes a recurring "we'll just write our own form handler" proposal from the backlog — the remaining gaps are presentation and workflow, not plumbing.
• Conversion-rate and compliance work: Translated placeholders on date, select, dictionary, and improved-select fields close a real UX gap in non-English funnels. Localized validation errors also matter for accessibility and consumer-protection expectations in multilingual markets.
• Risk posture / dependency decisions: The reCAPTCHA fix means a missing google/recaptcha package degrades to a warning instead of a hard error. This supports a decision to ship forms with spam protection optional per environment (e.g. staging, air-gapped demos, or a phased launch where reCAPTCHA is enabled only at go-live).
• Sequencing signal: All changes are additive or corrective, with one opt-in flag. This is a low-risk upgrade that can ride along with a regular maintenance window — no migration story, no stakeholder sign-off beyond the localization toggle owner.

When to Consider This Package

Consider it when:

• The stack is Laravel/PHP (and specifically Statamic, given the Marketplace distribution and multisite framing).
• You need standard lead-gen, contact, or survey forms with server-side validation and reCAPTCHA, and you want that as a dependency rather than in-house code.
• You run or plan a multisite/multilingual site where per-page-language error messaging is a requirement, not a nice-to-have.
• You want spam protection that can be present-but-inactive in non-production environments without breaking submissions.

Look elsewhere when:

• The front end is decoupled/headless and forms are owned by a separate service — you'd be duplicating validation logic across two systems.
• You need complex conditional branching, multi-step wizards with save-and-resume, payment collection, or submission workflow/approval routing. This package reads as a competent form handler, not a form platform.
• You require first-party enterprise support, SLAs, or a vendor security review — a Marketplace/community package with Discord-based triage won't clear procurement.
• You want zero third-party spam dependencies; reCAPTCHA is the assumed path here, and the release explicitly frames the google/recaptcha package as the expected companion.
• Submission analytics, A/B testing on form variants, or CRM sync are core requirements — plan to integrate rather than expect.

How to Pitch It (Stakeholders)

For executives: This release makes our forms usable in every language we sell in, with one config flag and no engineering rebuild. It's an opt-in setting, so we can launch it market by market. The other fix removes a failure mode where a missing spam-protection dependency could take a form down entirely — it now warns and continues. Net effect: broader market coverage, lower launch risk, no breaking changes, and no added headcount.

For engineering: Upgrade is additive — new localize_submissions config/env toggle, placeholder translation fixes across date/select/dictionary/improved-select fields, and a defensive guard around reCAPTCHA validation when the secret key is set but google/recaptcha is absent. No deprecations or migrations. Recommendation: bump the dependency, default the flag off in existing sites, and enable per-site once copy review is done for each locale. Worth confirming our own translation coverage for the new placeholder strings before flipping it on.