Filament Locale Picker Laravel Package

Product Decisions This Supports

• Localization of the admin surface, not just the customer surface. Most i18n roadmaps stop at the public app while support, ops, and regional staff keep working in English. A locale picker in the Filament panel closes that gap cheaply, and is a prerequisite for any "we support N markets" claim that includes internal users.
• Enterprise and multi-region deal qualification. Admin-panel language switching is a recurring checkbox in enterprise security/UX reviews. Having it shippable in days rather than a custom sprint changes how confidently sales can commit to it.
• Build vs. buy for a small, well-bounded UI concern. The underlying capability (a user-level locale preference plus a panel render hook) is maybe a day of engineering. Buying is justified only if it also carries persistence semantics, per-user preference handling, and Filament-version compatibility you'd otherwise maintain.
• Roadmap sequencing signal. The v1.0.1 fix targets view namespace registration in a render hook — the package is still stabilizing its integration seam with Filament's rendering API. Treat it as "adopt for non-critical panels now, promote to core panels after it has survived a Filament minor upgrade."
• Not a decision this supports: translation content management, locale routing for the public site, or per-tenant locale policy. Those are separate concerns this package does not address.

When to Consider This Package

Consider it when:

• You run a Filament panel with a genuinely multilingual internal user base (support, regional ops, in-country staff), not a hypothetical one.
• You are on a Filament version the package explicitly declares support for, and you have a tested upgrade path for Filament majors — the render-hook registration is exactly the kind of seam that breaks across majors.
• You want per-user locale as a preference rather than a global app setting, and you don't already have that concept in your user model.
• The panel is not the sole interface for a regulated workflow where an untested third-party view render is a compliance concern.

Look elsewhere (or build in-house) when:

• You need a single locale for the whole panel — a config value beats a package.
• You already have a preferences/settings subsystem; wiring a select into it is less code than a new dependency and its upgrade cadence.
• You need locale switching tied to tenant, role, or content — this is a user-facing picker, not a policy engine.
• You require vendor SLAs, security review artifacts, or a maintainer bus factor above one. This is a small v1.x community package; assess it the way you'd assess any single-maintainer dependency, including pinning and a fallback plan.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost plugin that lets each admin-panel user choose their own language. It supports the "we operate in N markets" story on the internal side, which is where enterprise buyers actually look. Cost is a dependency and a few hours of integration, not a project. Recommendation: pilot on one non-critical panel, revisit at the next Filament upgrade.

To engineering: A Filament plugin providing a locale picker via a render hook. Current release is v1.0.1, a patch fixing the view namespace used in hook registration — a stability fix on its Filament integration, not a feature or a breaking change. No migration work implied. Ask for: a pinned version, confirmation of Filament compatibility with our current major, and a smoke test on panel render after any Filament upgrade. If the hook seam proves brittle, the fallback is a native select bound to a locale column — a contained, one-day replacement.