Nova Locale Switcher Laravel Package

Technical Evaluation

Architecture fit. This is a thin Nova front-end tool: a service provider that registers a tool with Nova::tools([...]) and a compiled Vue component that renders a locale dropdown in the Nova UI. It is deliberately scoped as UI only — the README states it ships "without any concrete localization implementation," meaning the package does not set app()->setLocale(), does not route or persist the selection, and does not translate anything. Architecturally it is a presentation-layer convenience, not a localization framework. Any team expecting the latter will be disappointed; any team that already has a localization layer (session/user-preference locale, middleware calling App::setLocale()) can treat this as a small rendering shim.

Integration feasibility. Installation is standard Composer + NovaServiceProvider::tools(), with likely a publishable config listing available locales. Effort to get pixels on screen: under an hour for a competent Laravel developer. Effort to make it actually localize the admin panel: 1–3 days, because you must build the persistence and middleware layer yourself. The real integration question is not the package, it's whether you own the locale-resolution contract (where is locale stored — session, users.locale column, cookie? what wins on conflict? how does it interact with API requests?).

Technical risk. High, concentrated in a few places:

• Staleness. Last release 2020-10-29. Laravel Nova 4 (2021) and Nova 5 (2024) both moved the front end forward; Nova 4 in particular changed asset/tool conventions and Vue major version. A 2020 Nova 3-era tool has a materially non-trivial chance of not registering or rendering correctly on current Nova. This is the single largest unknown.
• Commercial dependency compounding. Nova itself is a paid, closed-source package. You cannot run CI against it without a license, so any fork you take on inherits a testing-environment cost that is invisible in the repo's own (absent) test suite.
• Zero adoption signal. 13 stars, 0 dependents, single-vendor provenance (Eolica-Web). There is no community to absorb breakage, no fork ecosystem, and no evidence of production use at scale. The 0.495 score and 13.4 opportunity score align with this.
• Facade risk. Because it does no localization itself, a working switcher can appear to work while the application's locale is unchanged — a silent mismatch that erodes admin trust in the feature.
• Bus factor 1, unmaintained. No security surface of note (a dropdown reading a config array), so the risk is functional, not CVE-driven.

Key questions.

1. Which Nova major version does the shipped asset target, and has anyone validated it on Nova 4/5?
2. How is the selected locale persisted — POST to an endpoint, query string, localStorage, or not at all? Where does it write?
3. Does it dispatch an event or call a documented hook we can bind middleware to, or must we fork to add persistence?
4. Is a compiled dist/ committed, or does it require npm build from source with a Vue toolchain version we'd have to match?
5. What does the config expose — locale list only, or also default locale and labels?
6. Is the MIT license unambiguous for a fork-and-vendor, and are there any Nova-license constraints on redistributing compiled assets?

Integration Approach

Stack fit. Fits standard Laravel + Nova projects on PHP 7.4–8.x. It is a Nova-only artifact: it adds nothing to the application layer, the API layer, or any non-Nova surface. If your admin is not Nova, this package is irrelevant.

Migration path. Given the age and zero dependents, the correct framing is not "adopt a dependency" but "acquire a 100-line component." MIT licensing makes that clean. Three options, in order of preference:

1. Reimplement in-house (recommended). A Nova custom tool or a header component plus a small controller and SetLocale middleware is a day's work, is testable without a fork debt, and gives you full ownership of the persistence contract.
2. Fork and vendor. Copy into packages/ or app/Nova/Tools/, pin the Vue build, add tests. Acceptable if your team is Nova-fluent and time-boxed.
3. Install as-is. Only defensible as a same-day spike to demo the UX, not as a production dependency.

Compatibility. Verify against your exact laravel/nova constraint before anything else; treat Nova major-version compatibility as a gate, not a detail. Confirm PHP and Laravel version bounds in composer.json, and confirm whether the tool tolerates Nova's asset versioning. If your Nova is v4+, assume breakage until proven otherwise.

Sequencing.

1. Spike (0.5 day): install in a throwaway branch, confirm render on your Nova version. Kill the option immediately if it fails.
2. Define the locale contract (0.5 day): decide storage (recommend users.locale for admins, session fallback), precedence rules, and default.
3. Build persistence + middleware (1 day): enforce App::setLocale() on every Nova request; make the switcher reflect state rather than own it.
4. Implement actual localization (the real work, unbounded): translation files, locale-aware validation messages, date/number formatting, and — the frequent cost sink — translated content (models/DB columns) if admins edit multilingual records.
5. Roll out behind a config flag to internal admins first.

Operational Impact

Maintenance. Effectively unmaintained upstream: no releases in roughly four years, no visible CI, no test suite, single-vendor provenance. Your team owns every future fix regardless of whether you install or fork — which further tilts the decision toward forking or reimplementing. Budget a recurring line item for "re-verify on every Nova major upgrade."

Support. No SLA, no commercial backing, no issue-triage cadence. Dependency resolution questions go to a dormant GitHub issue tracker. Team must be self-sufficient in Nova tooling — a common and acquirable skill, but not free.

Scaling. Negligible runtime cost — a config array and a rendered dropdown. No database, no queue, no external calls, no cache surface. It will not be your bottleneck at any scale. The scaling concern is organizational: every additional locale multiplies translation surface, QA matrix, and content-authoring effort, none of which this package addresses.

Failure modes.

• Silent no-op: switcher changes but app()->setLocale() never fires; admins believe they are editing the French site while writing English content. Highest-severity failure because it is invisible.
• Nova upgrade breakage: tool silently drops from the UI after a Nova bump; no error, just disappearance.
• Asset/build drift: if the tool requires a source build, a Vue toolchain mismatch blocks installation entirely.
• Persistence ambiguity: locale resetting per request or per session causes user-visible flapping.
• Partial localization: mixed-language admin UI (translated chrome, untranslated validation/notifications) reads as a bug, not a feature.

Ramp-up. Low for anyone with Nova experience — a day to read the package, a day to wire persistence. The genuine ramp-up cost sits downstream, in standing up the localization infrastructure this package deliberately omits. Plan and staff for that, not for the switcher.

Verdict for the TPM. Low score, near-zero adoption, four-year-old release, and it does not perform the function its name implies. Recommended action: do not take it as a production dependency. Run a half-day spike for UX reference, then implement or fork in-house. The package is a two-hour solution to a visible problem; the invisible problem — locale persistence and actual translation coverage — is where the budget belongs.