Statamic One Click Content Translation Laravel Package

Product Decisions This Supports

• Localization roadmap and market sequencing. One-click translation from inside the Statamic control panel turns "launch locale N" from an engineering project into a content-ops task. This directly supports decisions about which markets to pilot next, since cost per additional locale drops and lead time is measured in editor hours rather than sprint capacity.
• Build vs. buy for the translation pipeline. The package already covers the expensive, undifferentiated plumbing: provider integration (DeepL and Google), field-level content extraction, and round-tripping translated values back into entries. Buying here frees engineering for differentiated work — review workflows, terminology governance, and publishing checks — rather than maintaining an API client.
• Locale granularity strategy (new in 6.0.8). Target language now derives from the Statamic site config (locale/lang), with an optional translation_locale attribute for exact codes such as en-US or pt-PT. This forces an explicit product decision that was previously implicit: do we ship one English or distinct en-GB/en-US variants? Do we serve pt-BR and pt-PT separately? That is a positioning and SEO question, not a technical one, and it now has a first-class configuration answer.
• MT provider selection and reversibility. Support for both DeepL and Google means provider choice is a commercial/quality decision that can be revisited without re-architecting. The DeepL glossary constraint (keys must be DeepL codes like DE, EN-US) is the one place where switching costs real effort, so glossary investment should be tracked deliberately.
• Editor adoption and internal rollout. UI texts are now translatable (EN, DE). This is a leading indicator for which internal teams can self-serve translation — German-speaking editorial teams can adopt without a translated admin layer, which affects rollout sequencing and training investment.
• Terminology governance as a product artifact. Glossaries encode brand names, legal disclaimers, and product terminology. Owning this as a curated, versioned asset (not an engineering afterthought) is the main lever on MT output quality and therefore on how much human review each locale needs.

When to Consider This Package

Consider adoption when:

• The site is built on Statamic with multi-site already configured in resources/sites.yaml. This is a Statamic addon, not a general-purpose Laravel package — a plain Laravel application gains nothing from it.
• Content volume or locale count makes manual or agency translation a throughput bottleneck, and a machine-translation-plus-editor-review workflow clears your quality bar.
• You need a credible first-pass draft fast — for launch content, long-tail pages, or low-risk marketing copy — with editors polishing rather than translating from scratch.
• The team can own two operational steps: a sites.yaml configuration change, and a deploy-time php artisan vendor:publish when control-panel assets are missing.
• Provider flexibility matters — you want DeepL's quality for European languages with Google as a fallback, rather than committing to a single vendor.

Look elsewhere when:

• You are not on Statamic. No benefit to a Laravel-only or headless-API-only stack.
• Content is regulated or contractual. Legal, medical, financial-disclosure, or safety-critical copy needs certified human translation; MT output is a draft, never the deliverable.
• You need TMS capabilities. Cross-system translation memory, per-string review state, vendor management, word-count and cost reporting, and translator portals are outside this package's scope.
• You cannot absorb a breaking change on a patch version. Release 6.0.8 silently changes the target locale for region-less codes (en → EN-GB, pt → PT-BR). Any site relying on the previous implicit mapping must audit every site's resolved locale and pin it via translation_locale before upgrading.
• You have significant DeepL glossary investment keyed to non-DeepL codes. Migration to DeepL codes (DE, EN-US) is mandatory and needs scoping.
• You lack a process to re-publish assets. Missing CP assets break the editor UI until vendor:publish --tag=statamic-one-click-content-translation --force runs; treat this as a required deploy step, not a troubleshooting note.

How to Pitch It (Stakeholders)

For executives: This addon makes translation a one-click editorial action inside the CMS instead of an external project. That compresses the cost and lead time of entering a new market, and lets us pilot locales without adding headcount or agency spend. Two caveats worth budgeting for: this is a patch release containing a breaking change to how target languages are resolved, so we need a short audit of existing site locales and glossary keys; and machine translation produces drafts, so quality still depends on editorial review and a curated terminology glossary, which we should own as a product asset.

For engineering: The integration surface is small and well-defined. Configuration lives in sites.yaml; the new translation_locale attribute replaces implicit locale inference with an explicit contract, which is the right long-term design even though it breaks the old behavior. Upgrade path: (1) decide and set the exact region code for every site, (2) migrate DeepL glossary keys to DeepL codes, (3) run the vendor publish command for CP assets. Recommend pinning the version, adding a smoke test that asserts each site's resolved target locale, and treating the publish step as part of the deploy pipeline. The breaking change shipping in a patch release is a versioning-discipline signal worth flagging in our dependency review.

For content and editorial leads: Editors get a usable first pass with a single click, and the admin UI is now available in English and German. The lever that determines quality is the glossary — brand names, product terms, legal phrasing — so a short governance doc and one owner per language pair is the highest-leverage investment we can make alongside the upgrade.