Nova Locale Manager Laravel Package

Product Decisions This Supports

• Localization / market-expansion roadmap. This is the admin surface for the "which languages and markets do we support" decision. It turns locale enablement from an engineering ticket into a product-ops action: add a locale, set a default, disable a market — without a deploy. That shortens the loop between a go-to-market decision (launch in NL, FR, DE) and the app actually reflecting it.
• Build vs. buy on admin plumbing. The honest framing: this is a thin Nova resource over a locales table, not a translation platform. It is a "buy" only because the buy price is near zero (MIT, no vendor contract). The real decision is whether locale management belongs in an internal admin panel at all, or should be config/env-driven and change-controlled. If locales change rarely and only engineers touch them, this package is buying something you already have.
• Feature scoping: locale management vs. translation management. This package manages locale records — not strings, not translation memory, not vendor handoffs. It pairs with (does not replace) something like outl1ne/nova-translatable or a TMS. Decision to surface: are we solving "editors can turn on a language" (this) or "editors can ship translated copy" (not this)? Conflating them is the most common mis-scope here.
• Operational use cases it enables: regional marketing landing pages, per-market pricing/catalog views, support coverage in new regions, and staged rollouts where a locale exists in the DB but is disabled for end users. Each is a small but real reduction in cross-team dependency on engineering.
• Vendor/technical-debt posture. Adopting it is a statement that you accept a single-purpose, low-traffic dependency in your admin layer. That is a legitimate decision — but it should be a decision, recorded, not an incidental composer require.

When to Consider This Package

Consider it when all of these hold:

• You already run Laravel Nova (a paid, per-site product) and are not adopting Nova because of this package.
• Your admin panel already leans on Outl1ne/Outl1ne-lineage packages (nova-translatable, nova-multiselect-field), so the UI conventions and maintenance expectations are consistent rather than additive.
• Locale changes are frequent enough that self-serve matters — content ops or marketing ask for a new market more than once a quarter.
• Locale count and structure are simple (a handful of records, flat attributes: code, name, default flag, enabled flag). Nothing multi-tenant, nothing per-locale permissioned.
• You can pin and verify compatibility against your Nova major version — the last release was July 2022, so treat Nova 4/5 support as unverified until you test or read the source (it is small enough to read in one sitting).

Look elsewhere — or build — when:

• You are not on Nova. Standing up a paid admin framework to get one CRUD screen is a poor trade.
• You need translation workflow, vendor/translator access, translation memory, or per-locale RBAC — that is Lokalise/Crowdin/Phrase territory, or spatie/laravel-translatable plus your own resource.
• Your environment has meaningful dependency-review or supply-chain requirements. 16 stars, one last release in 2022, and a 0.14 score describe a package that is effectively maintenance-frozen; "MIT and tiny" mitigates severity, not the review finding.
• Locales are structural and rarely change. Env/config plus a migration is simpler, reviewable, and has no upgrade coupling to Nova.
• You need multi-tenant or per-market locale sets — the data model here is almost certainly single-tenant-flat, and bending it costs more than writing it.

How to Pitch It (Stakeholders)

For executives (30-second version). This is a small, free, open-source admin screen that lets our operations team turn languages and markets on and off without filing an engineering ticket. The value is not the code — it is removing a recurring class of small requests and letting a market launch proceed on the business team's timeline rather than the sprint's. Cost is near zero in license terms and roughly half a day to a day of engineering to vet, pin, and test. The caveat is candid: it is a low-adoption package with no releases since mid-2022, so we should treat it as a convenience layer we are willing to fork and own, not as a platform dependency. It does not translate anything and does not replace a translation vendor; it only manages the list of locales the product supports.

For engineering. It is a thin Nova tool over a locales table — a resource with a handful of fields. Two asks: (1) confirm compatibility with our Nova major and pin the version; if it is stale, fork it into our namespace — the surface is small enough that forking is cheaper than waiting on upstream. (2) Keep the locales table and any domain logic ours; the package should be a view onto our data, never the owner of it. Add a smoke test around locale creation and default-locale switching so a Nova upgrade fails loudly rather than silently. Budget: half a day to a day, most of it verification.