Statamic Magic Translator Laravel Package

Product Decisions This Supports

• Localization coverage vs. manual re-entry. v0.4.0 closes a real gap: localizable Group fields — including nested groups and fields pulled in from fieldsets — now translate, while non-localizable and opted-out children are left alone. For a PM this converts "our content model has groups/fieldsets everywhere, so translation still needs a human cleanup pass" into a defensible automation claim. It directly affects launch readiness for any locale where editors currently hand-fix nested content after each batch.
• Content model flexibility. Because fieldset-imported fields are now in scope, product and content-architecture decisions (reuse fieldsets aggressively, nest groups for structured content like hero blocks or FAQ sets) stop being penalized at translation time. That removes a recurring "don't over-structure the content model" constraint from design reviews.
• Data integrity on translated entries. The Link field fix (#46) is the more commercially important line item: translated entries no longer lose core Link field URLs and entry references, and link-only entries keep their references when a localization is created or overwritten. Broken CTAs and dead internal links in a translated market are a customer-facing defect, not a formatting nit — this is a quality-gate item you can now de-risk rather than QA manually per release.
• Build vs. buy. The package is accumulating the unglamorous edge cases (nested groups, fieldset imports, reference-preserving overwrite semantics) that make in-house translation scripts expensive to own. Each release like this shifts the build-vs-buy math toward adoption and away from a bespoke internal translator.
• Roadmap sequencing. The pattern of releases is "expand field-type coverage, then harden integrity." That suggests planning localization-dependent features (new locale launches, translated landing pages, regional campaign sites) after coverage for your specific field types is confirmed, not on the package's version number alone.

When to Consider This Package

Consider it when most of the following hold:

• Your content is modeled in a way this package understands — Groups, fieldsets, Link fields, entries and localizations. v0.4.0 specifically rewards teams whose content model leans on nested Group fields and shared fieldsets, which was previously the awkward case.
• You are running multi-locale/multi-site content and the bottleneck is repeatable, programmatic translation of structured entries rather than one-off marketing copy.
• You can absorb pre-1.0 churn. At v0.4.0 the API and behavior are still settling; treat upgrades as planned work with a regression pass over translated entries, not a silent dependency bump.
• Your team is comfortable reading the source when an edge case appears — the maintenance signal here (Prettier version bumps alongside substantive fixes) indicates a small, active, single-maintainer-scale project, not a vendor with an SLA.
• You need localization workflow automation inside the existing CMS, and adding a separate TMS for structured content would duplicate the content model.

Look elsewhere or wait when:

• Your content relies on custom or third-party fieldtypes not covered by the current translation matrix — coverage is expanding release by release, so verify your specific field list before committing.
• You need vendor support, security review artifacts, LTS guarantees, or a published deprecation policy. A 0.x package is a poor fit for regulated or contractual delivery.
• Your localization is human-in-the-loop editorial translation with review states and glossary governance — that is a TMS/workflow problem this package does not claim to solve.
• You are not on the underlying platform, or you'd be adopting it solely for one field type; the integration cost won't amortize.
• Your risk tolerance for silent content defects is zero and you cannot add a post-translation link/reference check to your release process.

How to Pitch It (Stakeholders)

To executives: This is a small, focused piece of localization plumbing that removes manual rework from launching content in additional languages. The latest release extends automated translation to the structured parts of our content model (nested groups, shared fieldset fields) and fixes a defect where translated pages could lose their links and internal references. The business value is straightforward: fewer editor hours per locale, fewer broken links in market-facing pages, and a lower cost per additional market. The risk is maturity — this is a 0.x open-source package with a small maintainer base, so we should adopt it with a regression check on translated content and avoid betting a hard launch date on it without that check in place.

To engineering: The package now handles nested and fieldset-imported Group fields, correctly skipping non-localizable and opted-out children — that removes the post-translation cleanup we'd otherwise own. The Link field fix (#46) means URL and entry references survive localization create/overwrite, including link-only entries, so we can drop the manual link audit from the translation runbook and replace it with an automated assertion. Two asks: pin the version and treat upgrades as reviewed changes with a fixture-based regression test over a representative entry set, and confirm our custom fieldtypes are inside the current coverage matrix before we commit a launch date. No breaking changes are signaled in this release, but pre-1.0 semantics mean we should not assume that holds.