Statamic One Click Content Translation Laravel Package

Technical Evaluation

Architecture fit This is a Statamic addon (Statamic being a Laravel-based CMS), so it sits inside the existing Laravel application rather than alongside it — no separate service, no new datastore, no new auth boundary. It hooks into the Control Panel to expose a "translate this entry" action and resolves the target language from the Statamic site's own locale/lang configuration. That is architecturally the right shape: the CMS multisite config remains the single source of truth for what languages exist, and the addon reads from it rather than maintaining a parallel language registry. For a team already running Statamic multisite, the conceptual surface area is small.

Integration feasibility Feasible for a Statamic multisite install with a DeepL or Google Translation API account. Composer-installed, config-published, CP assets published via a tagged vendor publish command. The work is configuration, not engineering: mapping sites to target languages, supplying API credentials, and deciding which fields are translatable. The main feasibility question is not "can we install it" but "does our multilingual site model match the addon's assumption" — specifically that one Statamic site maps cleanly to one translation target.

Technical risk Three risks stand out in 6.0.8.

1. Breaking changes shipped in a patch release. 6.0.8 is a patch number, yet it changes translation target resolution and glossary key format. That is a semver-discipline red flag for a TPM: it means the version number cannot be trusted to predict blast radius, and every upgrade must be read rather than assumed safe.
2. Silent behaviour change on locale resolution. Sites configured with a bare locale (en, pt) previously resolved to one regional variant and now resolve to EN-GB / PT-BR instead. This is the highest-impact item: it will not throw an error, it will simply start producing differently-variant content. Existing translated entries keep their old variant, so you can end up with a corpus that is part EN-US and part EN-GB and no obvious signal in the UI. Any glossary or editorial QA keyed to EN-US also stops applying.
3. Forced asset republish. The remediation instruction is vendor:publish --force, which overwrites published assets in the application. If anyone has customised the CP assets or if the publish path is tracked in version control, this is a destructive operation dressed as a fix. It also implies the published-asset state can drift silently from the package state, producing "missing UI" failures with no error message.

Key questions

• What is the project's semver policy, and why did breaking changes land in a patch release? Is there an LTS or support window we can pin to?
• Does the addon write translations directly into the live entry, or into a draft/revision that an editor must approve? Is there a diff or rollback?
• Are translations executed synchronously in the request, or dispatched to a queue? What happens on timeout mid-entry across many fields?
• Which fields are translated, and can that be scoped per fieldset (excluding structured data, IDs, relationship fields)?
• How are DeepL glossary mismatches surfaced — hard error, silent fallback, or partial success?
• Is there a supported upgrade path or migration command for the glossary key format, or is it a manual re-key?
• What are the licensing terms and the release cadence for critical fixes?

Integration Approach

Stack fit Requires a Laravel + Statamic application with multisite configured in resources/sites.yaml. The addon consumes the existing site locale/lang attributes and adds one optional attribute (translation_locale). No new runtime, no new database, no new deployment topology. It does add an outbound dependency on DeepL or Google APIs — that is the only new external integration and the only new failure domain.

Migration path Treat 6.0.8 as a configuration migration, not a version bump.

1. Pin and inventory. Record the currently deployed version and the current resolved target for every site. Derive that from actual translated content where possible, not from config alone — the config is exactly what changed.
2. Make targets explicit before upgrading. Add translation_locale to every site in resources/sites.yaml (en-US, pt-PT, etc.) so the new locale-inference logic is never exercised. This converts a silent behaviour change into an explicit, reviewable config diff and is the single most important step in this release.
3. Audit DeepL glossaries. Re-key glossary entries to DeepL codes (DE, EN-US). Confirm each glossary is attached to the sites that need it; a glossary keyed to EN-US will no longer be picked up by a site now resolving to EN-GB.
4. Republish assets in a controlled step. Run the vendor publish in a branch, inspect the diff before committing, and confirm nothing locally customised is clobbered. Do not run --force blind on a shared environment.
5. Validate the language matrix. The release claims support for all DeepL/Google languages. Test the specific pairs actually used; DeepL's supported set is narrower than Google's, and the release notes do not enumerate it.

Compatibility Check the addon's composer constraints against the pinned Statamic major and PHP version before committing. Because breaking changes arrived in a patch, verify the previous minor line is still installable as a rollback target. Also confirm the glossary code format matches the DeepL API version currently in use — this is a coupled upgrade, not an isolated one.

Sequencing Config change → asset republish → glossary re-key → upgrade → verify. Run the whole sequence in staging against a database copy with realistic multilingual content, including at least one entry already translated to the old target variant, so the mixed-variant case is exercised rather than theorised. Ship to production with the site config change and the version bump in the same release, and gate it behind an editor comms note. Do not split config and code across releases — that manufactures exactly the inconsistent-corpus window the release notes warn about.

Operational Impact

Maintenance Ongoing cost is low but non-zero and mostly falls on release upgrades rather than runtime. Three recurring duties: read every changelog rather than trusting semver; republish CP assets when the release notes say so, and reconcile that against version control; and keep the glossary aligned with the site language map as sites are added. The glossary is the piece most likely to rot — it is maintained in a third-party console, not in the repo, so it drifts independently of the codebase.

Support Editor-facing support load concentrates in two places. First, the UI is only translatable into EN and DE — any other editorial locale sees English chrome, which is a minor but permanent papercut for non-English teams. Second, the language-variant confusion from this release is a support ticket generator: editors will notice Spanish content that looks subtly wrong before anyone notices the config resolved to a different regional variant. Publish the "which variant does each site target" table somewhere editors can find it.

Scaling Two ceilings. Cost and quota: translation is billed per character against a DeepL/Google quota, so bulk translation of a large back-catalogue is a spend event, not just a compute event. Budget it and rate-limit bulk runs. Throughput: if translation runs synchronously in the CP request, large entries with many fields will hit request timeouts; if it queues, you need queue workers and a way to surface partial failures. Establish which before any bulk operation.

Failure modes

• Silent variant drift — wrong regional target, no error. Highest likelihood, lowest visibility. Mitigated only by explicit translation_locale.
• Glossary not applied — mismatched or stale codes mean brand terminology silently stops being enforced, producing plausible-but-off-brand copy.
• Missing CP assets — the publish step is skipped or partially applied; the UI degrades with no obvious cause.
• API quota / auth failure — surfaces as a failed action; need to confirm it fails loudly and does not partially translate an entry, leaving half-updated fields.
• Partial multi-field translation — a timeout mid-entry leaves inconsistent content that looks translated. Confirm atomicity or at least a clear partial-failure signal.
• Destructive --force publish — overwrites local asset customisations during an upgrade.

Ramp-up Small. Half a day for the engineer doing the site-config and glossary work; a one-page editor guide covering the translate action, the review/approval step, and how to request a glossary term. The genuinely non-obvious knowledge is the site-to-variant mapping and the fact that glossary management lives outside the repo — write both down, because neither is discoverable from the codebase and both are load-bearing for content quality.