Product Decisions This Supports
- Whether to localize the admin surface at all. This package forces the real question: do internal users (regional ops, support, content editors) need the Nova admin in their own language, or is English-only acceptable for back-office? It enables that pilot at near-zero cost rather than committing a sprint to it.
- Build vs. buy for small admin affordances. The package is a UI toggle, not a localization system — "without any concrete localization implementation" means translation files, user-locale persistence, and content translation are all still your job. That reframes the decision from "adopt a package" to "do we vendor 50–100 lines of Vue/PHP or maintain a dependency?" For something this thin, in-house is usually the cheaper long-term bet.
- Roadmap sequencing for i18n. Useful as a scoping artifact: it isolates the switching mechanism from the translation content, clarifying that admin i18n is really three workstreams — (1) locale chooser in the UI, (2) translated strings (Laravel
lang files, Nova language packs), (3) translated content (e.g., spatie/laravel-translatable). This package only covers (1).
- Use cases worth validating before investing: multilingual content teams editing in their native language, regional support staff triaging tickets, and QA validating locale-dependent behavior (dates, currency, number formats) without changing their OS/browser settings.
- Risk/portfolio hygiene. At 13 stars, 0 dependents, and a last release in October 2020 — predating Nova 4 and 5 — the honest decision this supports is "do not add a stale dependency to a customer-facing admin," not "evaluate for adoption."
When to Consider This Package
Consider it only when all of the following hold:
- You are on Laravel Nova 2 or 3 (or are willing to fork and port it), and have verified it actually boots against your Nova version rather than assuming compatibility.
- You need just a switcher — a session- or user-level locale toggle in the Nova UI — and already have translated
lang files and a middleware/app config that reads the selected locale.
- Your team is comfortable vendoring or forking an unmaintained MIT package and owning its upgrades across Nova major versions.
- The blast radius is internal only: admin users, not end customers.
Look elsewhere — or build in-house — when:
- You're on Nova 4 or 5; the Vue/Inertia tooling changed and a 2020-era tool package is a likely compatibility and maintenance liability.
- You need per-user locale persistence (stored on the
users table, respected across sessions and API calls) rather than a transient switch.
- You need actual localization: translated Nova resource labels, field labels, validation messages, and navigation. That's Nova language packs plus Laravel
lang files, not this.
- You need translated model content (multi-language titles, bodies, SEO fields) — that's a translatable-fields package and a schema decision, which this package does not touch.
- You need public-facing locale switching with SEO implications (
hreflang, localized URLs, locale-aware routing). Different problem, different tooling.
- Your dependency policy requires active maintenance, security review, or a maintainer who responds to issues. 0 dependents and no releases in ~5 years are disqualifying signals for most governance checklists.
How to Pitch It (Stakeholders)
To executives: This is a tiny, free, MIT-licensed admin toggle for Laravel Nova that lets back-office users pick their interface language. It does not translate anything by itself — it's the on/off switch, not the wiring. It's been unmaintained since 2020 and has essentially no adoption (13 stars, 0 dependents), so I'm not recommending we take a dependency on it. The idea is worth ~1 day of engineering to replicate ourselves if admin localization makes the roadmap; the package is useful mainly as a reference implementation and as evidence that the switcher itself is the cheap part of i18n — the translation content and per-user persistence are where the real effort lives.
To engineering: Treat this as a design reference, not a dependency. It demonstrates the minimal pattern: a Nova tool that sets the app locale (session or user record) and a middleware that reads it. If we build it, we own ~100 lines, control the persistence model (recommend a locale column on users), and avoid a Nova-major upgrade tax on an abandoned package. Pair it with Laravel lang files for UI strings and a translatable-fields package for content — this package covers neither.
Bottom line for the decision log: Do not adopt. Reimplement in-house if admin locale switching is prioritized; defer if admin i18n isn't on the roadmap, since a switcher without translated content delivers no user value.