Nova Translatable Laravel Package

Technical Evaluation

What the package is. yeswedev/nova-translatable is a Laravel Nova form-field package that wraps standard Nova fields (Text, Textarea, Trix, Slug, Markdown, etc.) so that a single JSON-backed column can be edited per locale, typically rendered as locale tabs or a locale dropdown. It is functionally in the same problem space as spatie/laravel-translatable (storage) plus a Nova presentation layer. It exists to solve a real, recurring need: giving content editors a sane UI for multi-locale attributes without hand-rolling a custom Nova field for every resource.

Architecture fit. The package sits at the presentation edge of the stack — it is a Nova field, not a domain library. That is architecturally cheap: it does not touch routing, queues, persistence semantics, or the API surface. Storage remains a JSON column read/written through Eloquent, so the backend contract is unchanged. This is a low-blast-radius dependency if it works, which is the crux of the evaluation.

Integration feasibility. Mechanically trivial — composer require, optional config publish, swap Text::make('title') for the package's translatable wrapper. Realistically, feasibility is gated by provenance rather than effort. The signal set is poor: 2 stars, 0 dependents, a composite score of ~1.14, and an opportunity score of 30.55 (i.e., the scoring model sees a large unmet need in this category and essentially no adoption of this implementation). A package with zero dependents has zero production feedback; there is no evidence base for correctness under Nova upgrades, no issue history to mine for known failure modes, and no community to catch regressions. The near-certain reading is that this is a low-traffic fork or re-implementation of the well-established outl1ne/nova-translatable (formerly OptimistDigital), which has orders of magnitude more adoption.

Technical risk.

• Abandonment / single-maintainer risk — high. Two stars and no dependents is the profile of a personal utility repo, not a maintained library. Assume no future releases.
• Supply-chain risk — moderate. An unfamiliar vendor namespace on Packagist, a Nova field that renders editor HTML, and no visible CI or security posture. Nova fields execute in the admin panel with authenticated-user privileges; a compromised or sloppy release is a privileged-context risk.
• Compatibility risk — high. The package must track three moving targets simultaneously: Nova major versions (4 → 5 changed field internals), Laravel (10 → 11 → 12), and spatie/laravel-translatable major versions. Nova's licensing and closed-source distribution make this triangulation harder than ordinary OSS.
• Correctness risk — moderate. Translatable-tab UIs classically suffer a validation gap: required rules on a locale the editor never opened can silently pass or silently fail depending on whether hidden tabs are mounted. Confirm behavior explicitly rather than assuming parity with the incumbent.
• Vendor lock-in — low. Field-level swap; uninstalling is a find-and-replace on resource definitions.

Key questions for the maintainer / before adoption.

1. Is this a fork of outl1ne/nova-translatable? If so, what was changed, and is the diff auditable? If not, why does a second implementation exist?
2. Which exact Nova, Laravel, PHP, and spatie/laravel-translatable versions are supported, and is there a CI matrix proving it?
3. License terms and whether the repo will accept patches (i.e., can we upstream fixes, or must we vendor?).
4. How are required, unique, and max rules enforced across non-active locales?
5. Does it support fallback-locale display, and is fallback read-only or write-through?
6. Is Nova search/indexing on translated columns supported, and does it query the JSON path or the active-locale key?
7. Test coverage and last-commit date — is the repo live or dormant?

Integration Approach

Stack fit. Appropriate only for a Laravel + Nova admin stack already using JSON-column translations (typically spatie/laravel-translatable). It is not applicable to per-row translation tables, and it has no bearing on public-site i18n or API localization — those remain separate concerns. If the product does not use Nova, this package is irrelevant and the evaluation terminates here.

Migration path. Two scenarios:

• Greenfield (no existing translatable UI): lowest-risk path. Adopt behind the incumbent's API shape if possible, so a later swap is a one-line change per field.
• Replacing an incumbent (outl1ne/nova-translatable): assume API drift. Expect differences in the wrapper constructor, locale-source config key, and how rules are applied per locale. Budget for a resource-by-resource diff rather than a global search-and-replace.

Data migration is not required — the JSON column shape is dictated by spatie/laravel-translatable, not by the Nova field. That is the single biggest de-risking factor: the persistence layer is portable even if the field package is not.

Compatibility gate (do this before any code is written).

• Confirm Nova major version; confirm the package's composer.json constraint admits it.
• Confirm PHP version (8.2/8.3) and Laravel major.
• Confirm spatie/laravel-translatable major aligns.
• If any constraint is * or absent, treat that as a red flag and read the source.

Sequencing.

1. Provenance audit (0.5 day): diff against the incumbent, read the field class, check license, last commit, tests.
2. Decision fork: if the audit is clean and constraints align, proceed; if not, adopt the incumbent (outl1ne/nova-translatable) — it solves the same problem with a real adoption base. This package's low score is a reason to compare, not to reject outright, but the burden of proof sits with the challenger.
3. Spike (1–2 days): install in a disposable branch, wire one low-traffic resource with 3 locales, exercise create/edit/validate/save, test the "required field on unopened tab" case, and test a Nova version bump in a scratch container.
4. Vendor/pin: commit a lockfile pin; if adopted, mirror the repo internally (Composer VCS or a private fork) so a deleted upstream repo cannot break builds.
5. Pilot (1 sprint): one content model in staging, editor sign-off on the tab UX.
6. Rollout: remaining resources, then remove the incumbent.
7. Exit ramp: document the revert — it is a field-class swap, keep the diff small enough that reverting is a PR, not a project.

Keep the wrapper calls isolated behind a thin internal helper or a single resource trait so that whichever package wins, the swap surface stays one file.

Operational Impact

Maintenance. The dominant cost is not the code — it is ownership. With 2 stars and no dependents, assume you are the maintainer from day one. That means vendoring, owning Nova-upgrade compatibility, and absorbing any upstream silence. Budget a recurring, low-frequency but non-zero line item: every Nova major and every spatie/laravel-translatable major becomes your upgrade. Compare that to the incumbent, where the community absorbs most of that cost. If the audit shows this package is a near-identical fork, the operating model is "we forked for a reason; document the reason or don't fork."

Support. No meaningful upstream support channel. Internal runbook required: who owns the fork, where the pinned version lives, how to patch. Editors will file bugs against the tab UX, and those bugs route to your team, not to a vendor.

Scaling. Runtime cost is negligible — it is form rendering and a JSON column read/write. The scaling concern is editorial, not infrastructural: rendering N locale tabs multiplies form fields and payload size linearly. At 3–5 locales this is invisible; at 15+ locales per resource the Nova edit screen becomes slow and cognitively hostile, and per-field validation cost grows. Also note JSON-column translation is a deliberate trade-off: it optimizes write simplicity and degrades query/index flexibility. If translated content needs to be filtered, sorted, or full-text searched per locale at scale, revisit the storage model — and no Nova field package can fix that.

Failure modes.

• Silent validation bypass on unopened locale tabs — the highest-impact failure, because it corrupts content quietly rather than erroring.
• Nova upgrade breakage — field API changes render the input inert or throw on mount; usually discovered in staging, occasionally in production if Nova auto-updates.
• Missing/renamed locale config — falls back to app.locale, silently collapsing a multi-locale form into a single-locale one; editors won't notice until content is wrong.
• Malformed JSON in the column — decode failure surfaces as a broken field rather than a clear error.
• Upstream disappearance — repo deleted or Packagist metadata pulled; builds fail on a clean checkout unless vendored.
• Unaudited privileged code — a Nova field renders in an authenticated admin context; a bad release is a privileged-context incident.

Ramp-up. Low for anyone who has used Nova: the mental model (wrapper field + locale source + JSON storage) transfers directly, roughly half a day for a mid-level Laravel developer. The non-obvious parts — how fallback locales behave on save, how rules apply per locale, and where the locale list is configured — are exactly the parts with no docs and no issue history to consult, so they must be written down internally during the pilot. Front-end/content-editor ramp-up is the real workstream: locale tab conventions, fallback expectations, and a "what does an empty tab mean" policy need to be decided by product, not discovered by editors.

Recommendation. Do not adopt on the strength of this package's own signal — 2 stars and 0 dependents is insufficient evidence for a dependency that touches editorial content integrity. Run the provenance audit first; if it is a clean, maintained fork with a documented reason to exist, a one-resource pilot is justified. Absent that, the same requirement is met by the established incumbent with materially lower ownership cost, and no architectural decision here forecloses switching later — the JSON storage layer is portable either way.