Nova Translatable Laravel Package

Product Decisions This Supports

Localization roadmap sequencing. This package is a concrete input to the "ship multilingual admin editing now vs. defer" decision. It buys time-to-first-localized-admin-screen — not a localization program. Frame the decision as whether to accelerate the first localized edit form, not whether to invest in i18n. The package adds no capability we couldn't build; it shortens the path to a demo.

Build vs. buy for admin tooling. It sharpens the recurring "custom Nova field vs. community field" call. At 81 stars, zero dependents, no release since 2021-08-29, and archived, it should be valued as a reference implementation to vendor or fork, not a dependency to composer require. The realistic in-house equivalent is ~1–2 engineer-days, which reframes the decision from "adopt vs. build" to "build with a head start vs. build from scratch." That delta is UI polish, not architecture.

Vendor lock-in and license renewal review. It forces the explicit question of how much of our content-ops surface depends on Laravel Nova — a paid, licensed product on an annual major-version upgrade clock — plus a single-maintainer field sitting on top of it. Relevant to Nova license renewal timing and long-term CMS strategy: a dead field on a paid framework couples our renewal cadence to an unmaintained dependency.

Content-ops use cases it unblocks. Editor-facing locale switching on a single record, with translations stored as a JSON column. Fits marketing pages, product catalogs, and SEO metadata where one entity needs N language variants edited in one form — small locale counts (2–4), internal editors, no per-locale approval chains.

Risk register line item. The archived status is itself a decision input. If adopted, log it as "vendored, internally owned" with a named owner and a re-evaluation trigger (Nova major upgrade, PHP/Laravel upgrade, or the addition of a third locale).

Explicitly out of scope — do not let this package anchor these conversations: public-facing i18n, routing/locale negotiation, translation memory, machine translation, and editorial workflow (draft → review → publish per locale). Nova is a CRUD panel, not a TMS.

When to Consider This Package

Consider it when:

• You are already committed to Laravel Nova for internal admin and spatie/laravel-translatable for JSON-column translation storage. If either half is missing, the package has no job to do and the evaluation ends.
• The need is small and bounded: 2–4 locales, a small editorial team, internal-only tooling, no per-locale approval chains.
• You have in-house Laravel capacity to vendor the field, patch it, and own it. The code surface is small enough that the adopt-vs-rebuild gap is polish, not structure.
• You want a working reference for locale tabs, fallback display, and dirty-state handling in Nova before committing to your own implementation.
• Compatibility has been verified against your exact Nova major, Laravel, and PHP matrix. Do not assume this from the README — the last release predates several Nova majors and moved through Mix → Vite and Nova field-lifecycle changes.

Look elsewhere when:

• You are on a current Nova major (4.x or 5.x) — expect incompatibility; budget a fork explicitly, or skip.
• You need per-locale workflow: drafts, scheduled publishing, reviewer roles, cross-locale diffs, or translation audit trails. Wrong tool, wrong layer.
• You use separate translation tables rather than JSON columns (e.g., astrotomic/laravel-translatable). Different storage model, different field.
• You need maintained dependencies for compliance, security review, or SLA reasons. Archived + single historical maintainer + zero dependents is a hard fail on most vendor-risk checklists.
• A first-party equivalent — spatie/nova-translatable — satisfies requirements. A maintained first-party package is almost certainly the correct answer, and checking is hours, not days.
• You are not on Nova at all, or are evaluating headless CMS / dedicated TMS options. Wrong layer of the stack.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed admin-panel add-on that lets our editors translate content inside the Laravel admin we already run, without a separate CMS or a translation vendor. It is not a platform bet. The honest framing: the project is archived and effectively unmaintained, so treat it as a head start on a build we own, not a dependency we install and forget. The recommended ask is small — roughly one to two engineer-days to vendor and own the field — versus an estimated multi-week build from scratch or a recurring annual TMS contract for what is currently an internal-only need. Decision requested: approve the small build allocation, or defer localization until locale count and editorial-workflow requirements are clearer. Blast radius is limited to internal admin tooling; a failure degrades editorial workflow, not the customer-facing product.

To engineering: It's a single Nova field that renders locale tabs and maps them onto spatie/laravel-translatable's JSON column. The value is entirely front-end ergonomics — locale switcher, fallback display, dirty tracking — not novel logic, so the realistic plan is fork-and-own, not composer require. Concretely: evaluate the first-party spatie/nova-translatable first (hours), and only proceed if requirements diverge. Then pin a commit and consume it via a path/VCS repository under an org-owned namespace, audit for Nova API drift across major versions, verify the field resolution/hydration contract and Vue asset compatibility against the current Nova pipeline, and add a round-trip test asserting that a locale write does not silently overwrite sibling translations — that is the one plausible path to real data loss and the highest-severity failure mode. Budget 1–2 engineer-days steady state per year, spiking to roughly a week around a Nova major. Note plainly that with 81 stars, zero dependents, and no maintainer there is no downstream canary for breakage — we absorb that risk ourselves. If requirements grow past simple per-record locale editing, stop extending this and scope a proper editorial workflow instead.