Nova Translatable Laravel Package

Technical Evaluation

Verdict: A narrow, low-risk-to-try but non-trivial-to-own dependency. It remains the de facto community answer for translatable Nova fields, but it sits on a closed-source host (Nova) and a single-maintainer release cadence, so the real cost is upgrade tax, not integration effort. Release 3.1.0 is additive — native Nova Repeatable field support plus build-tooling modernisation — and does not change the verdict, but it does modestly widen the scope of "any input field" and provides the first third-party contribution signal we've seen.

Architecture fit

• Purely an admin-panel concern: it wraps existing Nova fields so each field's value is persisted under a locale key, and delegates storage/retrieval semantics to spatie/laravel-translatable (JSON column per attribute). It does not introduce a new translation store, service layer, or API surface — the domain model stays yours.
• Because it is Nova-only, it does not leak into runtime request handling. Production read paths continue to go through Eloquent's translated accessors, which means the package can be removed in an afternoon if needed (the data shape is the hard part, not the package).
• The package's value is concentrated in three things now: the locale switcher UI, the field-nesting/metacomponent plumbing, and (new in 3.1.0) the Repeatable-field adapter. All are things a team can rebuild, but rebuilding means re-implementing Nova internals that change between majors — that ongoing burden is precisely what you're buying out of. Repeatable support in particular is a non-obvious adapter (Repeatable carries its own internal field array and serialisation), so this release removes a rebuild task rather than adding one.
• It is a single-package solution with no transitive weight beyond spatie/laravel-translatable, which most multilingual Laravel apps already run. The Node 24 change is dev-tooling only (asset build) and introduces no runtime dependency.

Integration feasibility

• Drop-in for an existing Nova 4/5 + spatie-translatable stack: composer require, optionally publish config (locale list, default locale, fallback behaviour), then wrap fields. Effort for a pilot resource is measured in hours, not days.
• 3.1.0 expands the happy path to include Repeatable fields — relevant if our content model uses repeatable blocks (link lists, feature bullets, FAQ pairs, CTA groups). Confirm whether Repeatable is a native Nova field in our version or a third-party nova-repeatable-style package; the release note says "native Nova Repeatable," which is a narrower claim than "any repeatable field package."
• The friction is still concentrated in edge cases: file/image fields inside the wrapper, relationship and nested/dependent fields, fields with custom resolveUsing/fillUsing, and per-locale validation rules (rules must be expressed per locale key, and error messages are attributed to the nested key, which editors find confusing). Repeatable-inside-translatable adds a fourth nesting dimension — validate this explicitly rather than assuming the new support is fully orthogonal to the existing edge cases.
• Requires a Nova licence to even boot the app in CI — you cannot run the package's own test suite meaningfully without one. Treat all verification as internal verification; there is no public regression signal.
• No public Packagist dependents reported. Combined with modest star count, that means very little third-party validation of upgrade paths — you will be an early discoverer of breakage. The 3.1.0 contribution from an outside author is a mild positive signal for the project's health, but it does not change the absence of downstream validation.

Technical risk

Technical risk headline: none of these are architectural showstoppers; all are operational. The one that should influence the decision is still the Nova-upgrade coupling, because Nova is a paid, closed-source dependency on its own release cadence and this package must chase it. 3.1.0 slightly increases surface area (Repeatable) while slightly decreasing abandonment risk (external contributor) — net neutral on the decision, but it moves Repeatable from "rebuild it ourselves" to "verify it works."

Key questions to resolve before commitment

1. Which Nova major are we on, and does the current release tag declare support for it? (Release date metadata appears ahead of the current date — verify actual tags/changelog rather than trusting the feed.)
2. Is spatie/laravel-translatable already in the stack, and at which major? Version skew here is the most common install failure.
3. Do we use Repeatable fields, and are they Nova-native in our version? 3.1.0 claims native Repeatable support only — third-party repeatable packages are a separate question.
4. Do we need translatable relations, files/media, or blocks (e.g. page-manager style)? Each narrows what "any input field" actually means for us. Repeatable is now covered; the others are not.
5. What is our API/consumer contract today — do any external clients read these columns directly? That determines whether the JSON change is internal-only.
6. Who owns the fork if the maintainer goes quiet, and do we have the Nova expertise in-house to patch it?
7. How many locales, realistically? This drives index-render payload and editorial complexity more than the package itself does — and it compounds with Repeatable, since each repeatable item multiplies the per-locale payload.

Integration Approach

Stack fit

• Assumes Laravel (10/11/12-class), PHP 8.1+, Nova 4 or 5, and spatie/laravel-translatable on the model. If the existing models already use the HasTranslations trait and JSON columns, fit is near-perfect; if translations currently live in a separate translations table or in per-locale columns, this package is the wrong shape and the migration becomes the project.
• Legacy note: pre-rename releases shipped under the optimistdigital/ namespace. Confirm which namespace your Nova version expects before adding the constraint.
• 3.1.0's Node 24 bump only affects contributors building assets from source; consuming the package via Composer requires no Node toolchain. Do not let it imply a runtime requirement.

Migration path

• The package is reversible; the data migration is not. Converting a VARCHAR column to JSON requires rewriting existing rows into {"en": "…"} form and updating any raw SQL, reporting queries, or exports that read the column as a string.
• Repeatable fields store an array of sub-field values; wrapping them in a translatable layer produces nested JSON arrays keyed by locale. If any existing repeatable data lives in flat JSON today, plan an explicit shape conversion and a fixture-based parity test — this is the one place 3.1.0 changes what "backfill" means.
• Sequence the data change behind a compatibility window: keep the old column readable while the new one is backfilled, verify parity, then cut over. Do not couple the schema change and the Nova field change in one deploy — you want to be able to tell which one broke the admin.
• Downstream API consumers will see different values once app.locale varies. Freeze the API's locale selection explicitly rather than inheriting request locale.

Compatibility

• Pin exact versions of Nova, the package, and spatie-translatable in composer.json and record the tested matrix in the repo. Because Nova is closed-source, CI cannot prove compatibility; only staging can.
• Verify against a staging clone with production-like locale counts and content volume — locale-switcher performance issues only appear with real payloads, and Repeatable resources are the heaviest payloads in the admin.
• Note that 3.1.0 support for Repeatable implies a minimum Nova version that shipped the native field. Check the Nova changelog before adopting if we are on an older 4.x.

Sequencing

1. Confirm Nova major + spatie version; read the changelog against both, including the Nova version that introduced native Repeatable.
2. Spike on one low-traffic, low-blast-radius resource (e.g. a static content page) in a branch.
3. Validate the pain points explicitly: a file field, a relationship field, a field with custom validation, a nested field, and — new for this release — a Repeatable field with at least two sub-fields.
4. Data migration + backfill + parity check for legacy columns, including any existing repeatable payloads.
5. Roll out resource-by-resource; Nova resources are independent, so this parallelises cleanly.
6. Add a missing-translation report before the first non-default locale goes live to editors.
7. Document the editorial workflow (locale switcher, fallback semantics, repeatable-item behaviour) — this is the step most teams skip and then pay for.

Operational Impact

Maintenance

• Low day-to-day surface: no runtime services, no background jobs, no external calls. Maintenance cost is almost entirely event-driven — it spikes when Nova ships a major, then drops to zero.
• The maintenance risk is ownership, not complexity: one maintainer, modest activity, and a package whose correctness depends on reverse-engineering a closed-source product. 3.1.0 shows an outside contributor landing a substantive adapter plus a build-modernisation change, which is a genuine (if early) signal of a second pair of hands — worth tracking across the next two or three releases before it changes the risk rating. Budget roughly 1–3 engineering days per Nova major for verification plus possible patching, and pre-agree an internal fork policy under the MIT licence so a stalled upstream is a scheduling problem, not a blocker.
• Avoid letting this become load-bearing for a roadmap commitment without that fork contingency documented.

Support

• GitHub issues only; no vendor SLA, no paid support tier, no security response process beyond normal OSS norms. Escalation path is "fix it ourselves."
• Internal support burden lands on whoever owns the Nova admin — they will field "my translation disappeared" tickets that are almost always locale-state or fallback-behaviour confusion rather than bugs. Expect a small second wave of Repeatable-specific questions ("why did my whole block set disappear when I switched locale?") as that path is newer and less familiar to editors.

Scaling

• Horizontal scaling is a non-issue (stateless admin package).
• The scaling axis that matters is content dimensions: locales × translatable fields × records, now multiplied by repeatable item count where repeatable fields are wrapped. JSON columns grow proportionally, and Nova index listings render per-locale payloads, so index pages get heavier as locales, columns, and repeatable items increase. This is a UX/perf ceiling, not a correctness one.
• No indexing on translated values means reporting and filtering over translations should be treated as out of scope; if the business needs "find all pages missing a German title," plan a dedicated audit query or a denormalised search column rather than expecting the admin to provide it. The same applies to querying inside translated repeatable arrays — treat that as out of scope and design around it.

Failure modes

• Silent fallback: missing translations resolve to the default locale with no signal — the most likely way bad content reaches production. Detect with a periodic missing-translation report per resource/locale, extended to report per repeatable item index.
• Locale-state drift: editors editing the wrong locale tab and overwriting good copy. Low frequency, high rework cost, poor detectability. Mitigate with training plus review of diffs on high-value content.
• Validation ambiguity: per-locale rule failures surface against nested keys, so error messaging reads oddly — and nesting depth increases again inside Repeatable. Acceptable, but worth a UI note for editors.
• Repeatable adapter regressions: newly supported field type, thinner real-world coverage than the core wrapper. Detect by exercising it in the pilot resource rather than assuming parity with scalar fields.
• Upgrade breakage: Nova major lands, field macros or metacomponents change, admin breaks on upgrade day. Mitigate by pinning Nova and sequencing admin upgrades deliberately rather than opportunistically.
• Package abandonment: no security fixes or compatibility patches. Contained by MIT fork rights, but only if someone has the Nova skills to exercise them.

Ramp-up

• Developers already fluent in Nova: roughly half a day to be productive, including the config and the nested-field conventions; add an hour or two if Repeatable-wrapped fields are in scope, since that nesting is the least-documented path.
• Developers not fluent in Nova: add days, because debugging means understanding Nova's field lifecycle, not this package.
• Content editors: a short guided session on the locale switcher, fallback semantics, and repeatable-item behaviour is sufficient and should be mandatory before first use — this is the cheapest possible mitigation for the highest-frequency failure mode.
• Overall this is a low-commitment, low-blast-radius adoption with a modest, predictable upgrade tax. 3.1.0 is additive and does not alter the recommendation: approve for a pilot; gate broader rollout on the migration path for existing data and a documented fork contingency, and add Repeatable fields to the pilot's explicit verification checklist rather than treating them as implicitly covered.