Nova Locale Field Laravel Package

Technical Evaluation

Verdict: A narrow-purpose Nova form field that solves a real problem (per-locale content editing) but is a frozen artifact — archived, last release Feb 2021, 17 stars. Treat it as a source of design patterns or a fork candidate, not as a dependency you adopt on faith.

Architecture fit

• Scoped entirely to the admin surface: it is a Laravel Nova field, meaning it renders and validates inputs inside a Nova resource form. It carries no runtime role in the application layer — no middleware, no query scoping, no locale negotiation. That is good: integration blast radius is confined to backoffice CRUD.
• Requires Nova, which is a paid, closed-source admin panel. This package therefore sits behind a commercial license and a vendor-controlled upgrade cadence — your ability to patch the field is bounded by Nova's own extension API stability.
• Value is contingent on your localization model. "Manage multiple localisations of a model" can mean JSON-column translation (spatie/laravel-translatable style), per-locale rows, or locale-scoped field groups. Confirm which before evaluating anything else; the wrong assumption here invalidates the whole assessment.

Integration feasibility

• Mechanically trivial: composer require, register the field in a Nova resource, configure a locale list. A Laravel developer can have it rendering in under an hour.
• The blocker is version alignment, not effort. A Feb-2021 release targets the Nova 3 era (Vue 2 field components, PHP 7.x/8.0-era constraints). Nova 4 moved to Vue 3 and Nova 5 followed; a field of this vintage should be assumed non-functional on either until proven otherwise in a spike.

Technical risk

• Abandonment risk: high and realized. Archived plus zero releases in ~4 years means no security patches, no PHP 8.2+/Laravel 10/11 compatibility work, and no Nova 4/5 support. You inherit the maintenance obligation at adoption, not at upgrade time.
• Bus factor: 1 (and departed). The publisher (Optimist Digital) shipped a large Nova package suite and has since archived much of it. There is no community to lean on at 17 stars.
• Security surface: low. It is a form field, not an auth, upload, or query-layer component. Primary risk is silent data corruption (partial locale saves, overwrites on fallback), not exploitation.
• Opportunity signal: 4.29 against a 1.15 score is the interesting datapoint — the need is genuine and underserved, the artifact is weak. That pattern argues for rebuild or replace, not tolerate.

Key questions

1. Which Nova major version are you on today, and what is your 12-month Nova upgrade plan?
2. What is the underlying persistence model — JSON translation columns, per-locale child rows, or separate tables? Does the field write to the same shape your API/frontend reads?
3. Does it handle locale fallback, per-locale validation, RTL locales, and non-text fields (media, slugs, SEO metadata)?
4. What is the maintained alternative in your stack — spatie/nova-translatable, a first-party Nova 4/5 field, or a hand-rolled locale tab component?
5. If we fork it, who owns the fork, and what is the trigger to retire it?

Integration Approach

Stack fit

• Assumes Laravel + Nova + Composer. If you are not already on Nova (e.g., Filament, custom Blade admin, Inertia/Vue admin), this package is simply out of scope — do not let it become a reason to select Nova.
• Fits cleanly only when your localization is content-editing localization, not runtime routing/i18n. It is a CMS-surface tool.

Migration path

• Greenfield on Nova 3: viable as a stopgap, vendored rather than required from Packagist.
• On Nova 4/5: assume it does not work. Choose between (a) fork and port the field component to the current Nova field API, or (b) replace with a maintained field. Given the component's small surface area, (b) is usually cheaper than (a) unless the field's UX is load-bearing for editors.
• Away from the package: because the field only touches the admin form, replacement is a UI swap plus a data-shape verification — not a data migration, provided the underlying column schema stays constant. Confirm that explicitly before committing.

Compatibility

• Pin the fork/vendored copy to an exact Nova and PHP version. Do not allow composer update to drift it.
• Test on the oldest PHP you support and on the Nova version you will run in 12 months, not just today's.

Sequencing

1. Spike (1–2 days): install on a throwaway Nova resource in a branch, on your current Nova version. If it does not render, close the evaluation — the build-vs-replace decision is already made.
2. Data-shape audit: verify read/write against your translation storage with a real model containing 3+ locales and partial translations.
3. Decide: adopt-vendored / fork-and-port / replace. Record the decision with the retirement trigger.
4. Pilot on one low-risk resource with an editor who will notice silent save failures.
5. Roll out resource by resource; keep the previous editing path available until one full content cycle has passed.

Operational Impact

Maintenance

• Adoption equals ownership. There is no upstream to file issues against and no release to upgrade to. Budget a standing line item: ~1–3 days/year for PHP/Nova compatibility, plus the cost of the initial fork or vendor.
• Vendor the code into your monorepo (Composer path repository or a packages/ directory) rather than depending on Packagist, so a future maintainer can see and patch it without archaeology.

Support

• Internal-only. Document the field's behaviour, its storage contract, and the Nova version it is pinned to, in the same place your team looks for runbook entries. At 17 stars there is no forum, no Stack Overflow corpus, and no third-party knowledge to borrow.
• Editors are the real "users" — silent save failures become content incidents, not bug tickets. Give them a verification step.

Scaling

• Negligible. It is an admin form field; it does not sit on the request path for end users and does not affect throughput, caching, or query plans. The only scaling concern is locale count — a tab-per-locale UI degrades editorially past ~8–10 locales, and per-locale validation load grows linearly. That is a UX ceiling, not an infrastructure one.

Failure modes

• Silent partial save: a locale tab left unsubmitted or a validation gap drops translations without an error. Highest-impact failure; test explicitly.
• Upgrade break: Nova bump renders the field blank or throws in the browser console. Detectable only by manual QA of admin screens — add one to your upgrade checklist.
• Locale drift: the field's locale list diverges from the app's configured locales, producing orphaned or missing translations.
• Shape mismatch: field writes a JSON shape your API does not read (or vice versa), producing content that looks saved but never surfaces.
• Fork rot: the vendored copy quietly falls behind a Nova field-API change and is discovered only when an editor cannot work.

Ramp-up

• Hours, not weeks, for any Laravel developer — it is a small, conventional Nova field. The actual cost is discovery: understanding the original author's assumptions about locale storage, which are undocumented and no longer answerable by the author.
• Front-load that cost by having the spike owner write a one-page "how this field stores data" note. It is the single highest-leverage artifact for the next maintainer.