Nova Tab Translatable Laravel Package

Product Decisions This Supports

1. Where the localization budget goes: authoring friction vs. translation pipeline. This package only fixes one thing — the shape of the form an editor sees in Nova. It turns a stacked wall of duplicated per-locale inputs into one tab per language. That maps to a real roadmap fork:

• If the measured bottleneck is editors (slow turnaround, copy-paste errors between locales, secondary languages left half-empty because they're buried twelve fields down), this is a near-zero-cost fix.
• If the bottleneck is the translation workflow (translator handoff, review cycles, TMS sync, translation memory, fallback rules), this package contributes nothing. Fund a TMS integration instead.

Confusing those two consumes a sprint for no measurable gain. A PM should name which one is actually broken before adopting.

2. Build vs. buy on internal tooling — not on product differentiation. Reproducing the behavior in-house (a Nova field group that iterates the configured locale set and renders one tab per locale) is roughly 1–3 engineer-days, ~200 lines. That reframes adoption as an efficiency trade: adopt if it drops cleanly onto the current Nova version; build and own it if it doesn't. It should never appear on a customer-facing roadmap or be pitched as a product capability. It is admin ergonomics.

3. Scoping localization work by editor surface area. Value scales with locales × translatable fields per resource. Two locales and three fields — the stacked form is fine, skip it. Four or five locales across a content-heavy resource (title, body, excerpt, SEO meta, slug, hero copy) — the tabbed form is a genuine usability change worth a half-day single-resource pilot.

4. Dependency posture as an explicit, PM-owned risk decision. 84 stars, zero dependents, single maintainer, MIT. That profile reads "thin wrapper, adopt with eyes open." The decision isn't really should we use this — it's do we pin it, or absorb it into our own field class and own it indefinitely. Make that call before it lands on the roadmap, not after a Nova upgrade breaks the admin.

5. Fit criteria for the use cases it actually serves. Best fit: marketing/CMS-style resources, internal ops tooling, 2–5 locales, non-technical editors, and a stack already committed to Nova plus spatie/laravel-translatable (or an equivalent JSON-column / translations-table approach). Non-fit: public API i18n plumbing, automated fallback logic, translation memory, or any surface where translation is machine- or vendor-driven.

6. Metrics worth attaching to the pilot. Time-to-publish a localized record; count of secondary-locale fields left empty at save; editor-reported friction. These are cheap to capture during a timeboxed spike and turn a subjective "the form is too long" complaint into a defensible yes/no.

When to Consider This Package

Consider it when:

• We already run Laravel Nova and have already committed to a translatable-field approach (spatie/laravel-translatable with $translatable plus JSON or text columns). This is a presentation layer on top; it only pays off inside that stack.
• Editors are non-technical, locale count is ≥3, and translatable fields per resource are numerous enough that form length is a voiced complaint rather than a hypothetical.
• The cost is genuinely small: a Composer require, typically no migration and no publish step, and a rollback path of "revert the resource file and the Composer entry."
• We can pin an exact version, read the small source, and fork if the maintainer goes quiet. At this code size that contingency is realistic.
• A half-day single-resource pilot can answer the question. If it can't, the decision isn't ripe.

Look elsewhere when:

• We are not on Nova. This is Nova-specific and non-portable — zero value outside the admin.
• We have one locale today but a plausible i18n roadmap. Structure the resource and translation storage properly now rather than retrofit a UI wrapper onto a data model never designed for it.
• We need vendor support, an SLA, a security disclosure process, or verified compatibility across Nova majors. A single-maintainer package with zero dependents will lag Nova's next major.
• We already run a TMS (Crowdin, Lokalise, Phrase). The value lives in the integration, not the tabs.
• Nobody can own the Nova-upgrade tail. At minimum it must sit behind our own field class so a break costs a swap, not a refactor.

Diligence checklist — PM gating questions, not just engineering detail:

• Declared Nova, Laravel, and PHP constraint ranges, checked against what we actually run. The recorded last-release date (2026-10-20) is future-dated and must be treated as unverified until confirmed against repository tags and composer.json; any compatibility claim derived from it is unsubstantiated.
• Does it hard-require spatie/laravel-translatable, or does it tolerate Nova's native translatable fields and plain JSON columns?
• How are validation failures surfaced when the offending field sits in an inactive tab? This is the one that should worry a PM most: an editor can save incomplete or invalid localized content without ever seeing the error. That is a data-quality risk with business consequences, not a crash.
• Fallback-locale behavior when a translation is missing or empty.
• Test suite presence; whether Vue assets are pre-compiled or drag an npm build into our pipeline.
• Commit history and issue-response pattern over the trailing twelve months, particularly responses to Nova-version breakage.

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a small, free (MIT-licensed) add-on that improves how editors enter translated copy inside our Laravel admin, showing one clean tab per language instead of a long column of duplicated fields. It touches nothing customer-facing: no new infrastructure, no schema change, no public request path, effectively zero runtime cost. The upside is editor time saved per localized record and fewer half-empty translations; the downside is a small single-maintainer dependency we inherit at every Nova upgrade. Recommendation: approve a half-day spike on one real resource, adopt only if it drops in cleanly against our current Nova version, pin the version, and wrap it behind our own field class. If it doesn't fit, an equivalent in-house field is 1–3 engineer-days — so the worst case of the spike is still cheap.

For engineering — the framing that matters. Treat it as a thin presentation-layer wrapper over Nova's tab and field system, not a translation engine. It doesn't touch routing, persistence, or domain logic; it regroups fields we already declare, so the data contract is unchanged and each resource is an independent, revertible change. The real cost isn't adoption — it's the implicit commitment to track Nova releases for a package with 84 stars, zero dependents, and one maintainer. So: pin to an exact version, verify the Nova constraint against our install, confirm whether assets ship pre-built, and sequence it as inventory → single low-traffic resource pilot → Nova-upgrade dry run → resource-by-resource rollout. Test create, edit, validation-error-in-inactive-tab, and missing-translation paths before widening. Build it so removal costs a file revert, not archaeology.

For content ops and design. The pitch is concrete: switching languages becomes one click instead of scrolling past fields you can't read, which cuts mis-entry and makes secondary locales less likely to be left blank. The honest caveat to flag: validation messages can hide inside a tab you aren't looking at — so the pilot must confirm invalid content can't be saved invisibly before this becomes the default editing experience.