Nova Locale Field Laravel Package

Product Decisions This Supports

• Localisation scope for admin/back-office tooling. Decides whether editors can manage all locales of a record in one place (side-by-side or tabbed locale inputs in a Nova form) instead of juggling one resource per language or editing raw JSON. This is a workflow decision, not a runtime i18n decision — it affects editorial throughput, not what users see.
• Build vs. buy vs. fork for the admin translation UI. Gives a concrete reference implementation and a cost baseline: the problem is small enough that a bespoke Nova field, or a Filament equivalent, is usually a few days of work. Use it to price the "buy" option honestly rather than treating it as a strategic dependency.
• Content model / schema direction. Implies a storage choice — per-locale columns versus a JSON translation blob on the model. Useful input when weighing spatie/laravel-translatable-style JSON columns against dedicated translation tables with per-locale rows (the latter being what you'll need if translation volume or workflow grows).
• Roadmap gating for localisation investments. Helps separate three very different asks that get conflated: (a) translate the product UI, (b) translate editor-managed content, (c) run a translation workflow (vendors, review, approval). This package only serves (b), and only the editing surface of it. If the roadmap contains (c), this is not the tool.
• Vendor/tooling consolidation. A reason to standardise admin translation editing on whatever Nova or Filament already gives you, rather than accumulating single-purpose fields with different data conventions.

When to Consider This Package

Adopt only under a narrow set of conditions:

• You are already running Laravel Nova (a paid, licensed product) and the multilingual content lives in Eloquent models you control.
• The locale count is small and stable (roughly 2–5) and translators are internal staff, not an external vendor or agency.
• Your translation storage is already JSON-column or per-locale-column shaped, so the field maps cleanly onto existing data.
• You are on a Nova 3-era codebase or are willing to verify compatibility yourself — the last release was February 2021 and the repository is archived.
• You treat it as a fork candidate or reference implementation, not a maintained dependency. MIT licensing makes that legitimate; the 17-star count and archived status make it mandatory.

Look elsewhere if any of these hold:

• You have no Nova licence. The package is worthless without the host product, and Nova itself is a recurring cost. A custom admin panel or Filament is a cheaper starting point.
• You need it to keep working. Archived + no releases since early 2021 means no Nova 4/5 compatibility guarantees, no security patches, and no upstream fixes. Any bug is now your bug, at your expense.
• You need translation workflow. Roles, approval states, translation memory, machine-translation hooks, per-locale publishing, or vendor handoff are all out of scope — that's Lokalise, Crowdin, Phrase, or a purpose-built TMS.
• Locale count is high or growing. Inline multi-locale editing degrades badly past a handful of languages; you want a queue-based or per-locale review flow instead.
• You're not on PHP/Laravel/Nova, or you're mid-migration away from Nova — don't take on an archived field during an admin-panel migration.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source component that lets editors translate a piece of content into several languages from a single screen in our Laravel admin panel, instead of switching between language-specific views. The capability is genuinely useful for editorial efficiency, but the project is a micro dependency: 17 GitHub stars, no release since February 2021, and formally archived by its author. It is not a platform, it is not a translation-management system, and it will not be maintained for us. The recommendation is therefore not to adopt it as infrastructure, but to use it as a reference design: it shows us the shape of the solution, and because it is MIT-licensed we can copy or fork the few hundred lines involved if we want the behaviour. Decision requested: fund roughly 2–4 engineering days to build or fork this capability in-house if multilingual editing is on the roadmap, rather than adding an unmaintained third-party package to our dependency surface. Budget the cost of that small build, not a licence, and treat any ongoing saving as reduced editorial toil rather than a new capability.

For engineering (talking points): it is a Nova field wrapping multi-locale input for a model, MIT-licensed, archived, last tagged release Feb 2021 — so compatibility with current Nova versions is unverified and must be checked before any spike. Two viable paths: vendor it with a pinned fork and an owner assigned, or reimplement the field against our storage convention. If our storage is JSON-column-based, the reimplementation is small; if we need per-locale rows, approval states, or vendor handoff, this package is the wrong layer and we should scope the workflow separately. Either way, do not let it become an implicit dependency of the content model — the data shape outlives the field.