Switch Locale Laravel Package

Product Decisions This Supports

• Admin-panel localization roadmap. Decides whether multilingual admin UX is a “nice to have” or a shippable increment: a locale switcher is the smallest visible proof that the product supports non-English operators, and can be piloted before committing to full translation management.
• Build vs. buy for internal tooling. A 1-star, zero-dependent package is a concrete case for the “buy small, fork if needed” option — the capability is narrow enough that an in-house Nova card is a realistic alternative if the dependency proves unmaintained.
• Nova ecosystem investment. Signals whether the team treats Nova as a first-class surface for operational users (support, content ops, regional managers) or purely as an internal CRUD console. If the former, small UX gaps like locale switching become roadmap items.
• Localization support-cost analysis. Every manual locale toggle is a proxy for a support burden — tickets like “the admin panel is in the wrong language” or “our regional team can’t read the labels.” This package quantifies whether a low-effort fix reduces those tickets.
• Prioritization against higher-opportunity work. With a low opportunity score and minimal adoption, this competes directly against revenue-facing i18n work (customer-facing translations, content localization, RTL support). The PM decision is sequencing, not adoption.

When to Consider This Package

Consider it when:

• The stack is Laravel + Nova, and admin users are genuinely multilingual (regional ops, support, content teams) rather than an English-only internal team.
• The need is a quick, session-level UI switch for administrators — not persistent per-user language preferences, not customer-facing localization.
• The team is comfortable vendoring or forking a small package: with 1 star, 0 dependents, and a single maintainer, treat it as source code you own, not a dependency you trust.
• You want to validate demand cheaply — a pilot behind an internal flag is cheaper than building a Nova card from scratch, and the code surface is small enough to review in an afternoon.

Look elsewhere when:

• You are not on Nova — this is Nova-specific; the equivalent for the app itself is middleware or a locale-resolution layer.
• You need per-user persistent locale — Nova already supports user-level locale preferences; adding a separate switcher may duplicate or conflict with built-in behavior. Confirm this before building.
• You need translation management — managing language files, content translation (e.g., per-field translation of Eloquent models), or RTL layout is a different class of tool; evaluate mcamara/laravel-localization, Nova field-translation packages, or a dedicated TMS.
• Compliance, security review, or long-term maintenance guarantees apply — a single-maintainer package with near-zero adoption will not survive a vendor-risk review; budget for ownership.
• The locale is already resolved by domain, header, or user setting in a way the admin panel inherits — the switcher becomes redundant.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk experiment to make the admin panel usable for non-English teams. It is a single small UI control, not a platform commitment. The real decision is not “adopt this package” but “do we support multilingual operators at all” — and a pilot answers that with minimal spend. Because the package has one maintainer and effectively no adoption, we should plan to own the code: either fork it or replace it with a short in-house implementation. Treat it as a spike with a defined exit, not a standard.

To engineering: Evaluate as source, not as a dependency. Review the Nova version compatibility, confirm it does not conflict with Nova’s built-in per-user locale setting, and decide session-vs-persistent behavior explicitly. Budget a small fork if the upstream goes quiet — the feature is a few files, so the switching cost is hours, not weeks. Gate it behind a config flag so removal is trivial.

Recommendation: Pilot for one team or region, instrument locale-switch usage and related support tickets, and set a 60–90 day review. Standardize only if usage is real and the fork cost stays trivial; otherwise fall back to the platform’s native locale handling.