Nova Translatable Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. Whether (and when) to open new locales is usually gated on "can our team actually author content in those locales without engineering help?" This package removes that gate cheaply inside Nova — it turns any existing field (text, textarea, Trix, Markdown, SEO meta) into a locale-tabbed input. That makes "launch locale X" a content decision rather than an engineering project.
• Build vs. buy on admin i18n. The alternative is writing your own Nova field wrapper around a translation trait: a few days of initial work plus ongoing Nova-version upkeep. At an MIT package with a narrow surface area and now evidence of external contributors, the build cost is genuinely hard to justify — but only if you're already on Nova (see below).
• Which fields get translated. The package makes translation per-field, not per-model, which forces an explicit product decision per content type: product names/descriptions and marketing copy → translated; SKUs, internal notes, integration IDs, slugs with routing implications → not translated. Documenting this mapping is a product artifact, not just a dev task. With 3.1.0, structured/repeating content (feature lists, FAQ blocks, spec tables, rich content sections) is now in scope — previously that content typically had to be either flattened or left English-only, so revisit any content model you parked for that reason.
• Data model and reporting commitments. Translation values land in JSON-backed columns (typically via spatie/laravel-translatable). That's fast to ship but has downstream consequences for full-text search, analytics aggregation, CSV exports, and API response shape. The new Repeatable-field support makes this sharper, not softer: translated repeater content is nested JSON inside JSON, which is harder to query, index, and export than flat translated strings. Decide the storage approach early — migrating from JSON columns to per-locale tables later is a real project.
• Editorial workflow scope. The package is an editing UI, not a translation management system. It does not give you translation status, reviewer roles, approval gates, or TMS/vendor hooks. If your content ops require those, scope them as separate work rather than assuming the package covers them — this is the single most common scope surprise.
• Vendor and maintenance risk posture. Single-maintainer OSS with modest adoption, but 3.1.0 ships a community PR (Repeatable field support) and a toolchain refresh (Node 24), which is a positive maintenance signal rather than a guarantee. Keep the cheap hedge — pin the version, budget a half-day to vendor/fork if abandoned — rather than treating it as a blocker.
• Success metrics to instrument. Locales live, translation coverage per locale, time-to-publish a new locale's content set, and engineering hours avoided versus the custom-field estimate. For repeater content, add coverage-per-block as a separate metric — partial translation of structured blocks is easy to ship and hard to spot.

When to Consider This Package

Adopt it when most of these hold:

• You are already running Laravel Nova (a commercial license you've committed to) and have no plans to migrate admin panels. This package has no value outside Nova.
• Your translated content is field-level and form-shaped — names, descriptions, body copy, meta tags, and now repeating field groups — authored by internal staff or a small ops team.
• You need two to a handful of locales, and the editing experience matters more than workflow governance.
• Your models already use, or can adopt, a JSON-column translation trait; the package is a UI layer, not a storage engine.
• You want to validate a market before investing in a real CMS or TMS.

Look elsewhere — or plan to build — when:

• You're not on Nova. Filament has first-class translatable field support; a bespoke admin or headless CMS may fit better. Don't let a small field wrapper drive your admin-panel choice.
• You need translation operations, not translation input: approval chains, per-locale assignees, translation memory, machine-translation pre-fill, or vendor (Crowdin/Lokalise/Phrase) sync.
• Locale affects routing or discovery — localized URLs, hreflang generation, locale-aware sitemaps, per-market SEO. That's a separate application-layer concern; this package only handles the input fields.
• Search and reporting across locales are core. JSON columns make cross-locale faceting, sorting, and relevance work harder — and translated repeater content compounds this. Evaluate against per-locale tables before committing.
• You're on a Nova or Laravel version at the edge of the compatibility matrix. Verify explicitly against the package's release notes and your pinned Nova major — Nova majors have historically broken field packages, and Repeatable-field support means the package now tracks a Nova field type that must exist in your Nova version.
• Compliance requires locale-segregated data (e.g., region-specific data residency or audit trails on content changes).

How to Pitch It (Stakeholders)

For executives (one paragraph): Entering a new market currently requires engineering work to make our admin tooling accept translated content — a multi-day project per launch and a recurring maintenance cost. This is an MIT-licensed package that adds that capability to the admin panel we already pay for, without new licensing fees. The latest release extends coverage to repeating content blocks (feature lists, FAQs, spec tables), so it now covers essentially all of our authorable marketing and product copy, not just single text fields — converting locale expansion from an engineering backlog item into a content operations task. The main trade-off is that it's a small, single-maintainer open-source component: real but bounded risk, mitigated by version pinning, MIT licensing, and now visible outside contributions. Recommendation: adopt for field-level content translation, and treat translation workflow, localized routing, and search as separately scoped items so expectations stay accurate.

For engineering (bullets):

• Thin wrapper that makes any Nova field translatable, with a locale switcher in the UI; model-side translation storage is handled by a JSON-column trait (typically spatie/laravel-translatable) — confirm which trait the version we pin expects.
• 3.1.0 adds native Nova Repeatable field support — no new runtime or PHP dependencies, but note that translated repeater content produces nested JSON, which we should account for in query, index, and export paths.
• No forced migrations or schema opinions beyond the translation column; per-field opt-in, so we control blast radius.
• Verify Nova major and Laravel version compatibility against the release notes before pinning; Nova upgrades are the likely breakage vector. The Node 24 bump is build tooling only and does not affect the PHP/Nova compatibility matrix — don't read it as a compatibility signal either way.
• MIT + small codebase = forkable. External contributor activity in 3.1.0 is encouraging, but single-maintainer is still the honest risk picture; keep a contingency for vendoring.
• Known gaps we own: translation status/approval UI, locale-aware search indexing, nested-repeater query ergonomics, and API response shaping for locale fallbacks.

Ask: a time-boxed spike (roughly half a day) to confirm Nova compatibility and trait fit on one content model — ideally one with a repeating field so we validate the new 3.1.0 surface — then a decision on the JSON-column storage approach before any wider rollout.