- How do I install bezhansalleh/filament-language-switch in a Laravel app?
- Run composer require bezhansalleh/filament-language-switch, then add the plugin's path to your Filament theme.css using the @source directive pointing at vendor/bezhansalleh/filament-language-switch/** and rebuild your theme with npm run build. Finally, register the plugin by calling LanguageSwitch::configureUsing() in a service provider such as AppServiceProvider. You also need to provide your supported locales through the locales() method.
- Which Filament versions does this language switch plugin support?
- The package advertises support for both Filament 4.x and 5.x via its badges and version support section. Because it relies on Filament's render-hook system, treat any new Filament major as something to verify in your own test suite before upgrading. Pin your Filament major and check the maintainer's release history for compatibility fixes before rolling out a major bump.
- Does this package actually translate my application?
- No. It is purely a UI affordance that lets a user pick a locale; it does not translate content, manage translation files, or change locale resolution middleware. Your existing Laravel locale middleware and lang files must honor whatever locale the user selects. Think of it as the switcher widget, not a localization engine.
- How do I configure the available locales and the display mode?
- Use LanguageSwitch::configureUsing() with locales() to declare your supported locales and displayMode() to choose between a dropdown or a modal. For installs with many locales, DisplayMode::Modal combined with columns() keeps the list manageable. You can also set trigger(), flags(), and labels() to control how each locale is presented.
- Why is my language switcher rendering without styles or looking broken?
- Almost always this is a theme build issue. The plugin requires a custom Filament theme with the @source line added to theme.css, and the relative depth of the vendor path must be correct for your project. If your npm run build is stale or not wired into CI, the switcher ships unstyled, which degrades silently rather than throwing an error.
- How do I persist the user's selected locale between sessions?
- The plugin emits an event when a user changes locale, but persistence is your responsibility. Listen for that event in your own application and store the choice in a user column, a session key, or wherever your locale resolution middleware reads it. Decide upfront whether locale is a per-user preference or a per-session value, and make sure it survives logout if that is the expectation.
- Can I show the language switcher outside Filament panels, like on the login page?
- Yes, the plugin supports rendering outside panels via the visible() method with insidePanels and outsidePanels arguments. Be aware that exposing it on auth.login and auth.register widens the surface to unauthenticated users. The default route list may not match a customized panel, so verify it against your actual routes before enabling it.
- Can I exclude the switcher from specific panels in a multi-panel or multi-tenant install?
- Yes, panel exclusion and per-panel configureUsing() scoping are supported, so you can enable the switcher on some panels and not others. In multi-panel or multi-tenant applications, verify the behavior against your real panel count rather than assuming the defaults fit. Also check whether the profile exclusion rule matches how you call profile(isSimple: true).
- Where does the switcher appear and what trigger options are available?
- The plugin auto-detects your panel layout and adapts its trigger to the render hook it is placed in, so it can render as a topbar icon button, a sidebar nav item, a user menu entry, or a standalone floating pill. You can override the placement with renderHook() or force a specific style with trigger(). This keeps setup zero-config while still allowing full customization when needed.
- Is this package safe to adopt in production given it is maintained by a single author?
- The technical risk is low because the package is a view-layer dependency that cannot touch domain logic or the database, so removal is a composer remove plus deleting one config block. The main risks are Filament major-version coupling and theme build dependency, both of which you can mitigate by pinning versions and building your theme in CI. Persisting the user's locale remains entirely your application's job.