Localization Core Livewire Laravel Package

Product Decisions This Supports

• i18n scoping on the roadmap. This package tells you that the locale-switching UI — the picker, the session/cookie persistence, the redirect-back-to-current-page behavior — can be treated as a solved, near-zero-cost item. That lets you separate "we need translations" (a content and workflow problem) from "we need a switcher" (a solved UI problem) in roadmap conversations, and price them accordingly.
• Build vs. buy for a very small surface. The buy case here is thin on its own — a competent Livewire dev can rebuild a locale switcher in a day. The real decision it informs is buy vs. vendor-and-fork: at MIT with a narrow surface, adopting this is functionally the same as adopting a reference implementation you own.
• Architecture: presentation adapter vs. domain logic. Because this is explicitly a presentation layer for a separate core localization package, it supports the decision to keep locale negotiation, resolution rules, and persistence in the domain layer while letting the Livewire layer stay dumb and swappable. That is a defensible separation worth writing into your conventions even if you never install this.
• Feature candidates it unblocks cheaply: per-user locale preference stored server-side, tenant/account-level default locale, region-specific rollouts, "view as locale" for support and QA, and localized marketing or onboarding flows inside an authenticated app.
• Ecosystem signal, not a build signal. 0 stars, 0 dependents, and a single recent release mean this should be evaluated as an internal dependency, never cited as evidence that i18n is a mature, community-backed layer of your stack.

When to Consider This Package

Consider it when:

• You are already on Livewire, and ideally already inside the Liberu modular stack — this package assumes a sibling core localization module and will cost you more than it saves if you have to reverse-engineer that contract.
• You want a drop-in, session-persisted locale switcher with the boring correctness handled: current-locale display, switch action, redirect preserving the current route, and negotiation fallback.
• Your team is small enough that saving a day of UI plumbing is real value, and comfortable pinning and vendoring a dependency rather than relying on upstream responsiveness.
• You want a forkable, MIT-licensed starting point you can restyle to your design system — which you will almost certainly need to do, since the shipped markup will not match your component library or accessibility standards.

Look elsewhere when:

• You are not on Livewire, or not using Liberu Localization as the core — the adapter is the thin end of a contract you do not have.
• What you actually need is translated content — database-backed model translations, translation management UI, editorial workflows, or machine-translation pipelines. This package switches which locale is active; it does not give you anything to switch to.
• You need vendor support, an SLA, or a security review trail. Zero dependents and a single maintainer is a real supply-chain consideration for regulated or enterprise contexts.
• You have complex routing or multi-tenant URL strategies (locale-prefixed routes, domain-per-locale, per-tenant locale isolation). A generic switcher will fight your router.
• You need accessibility- and brand-compliant UI out of the box.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed UI component that handles the language-picker in our Livewire app — the button, the preference persistence, and the return-to-page behavior. It is not a translation product; it does not translate a single word of content. Its value is that it removes a recurring piece of plumbing from every screen we ship, at zero licensing cost and negligible integration effort. The honest caveat: it has no community adoption behind it, so we should treat it as code we are adopting rather than a vendor we are relying on — pin the version, vendor it, and plan to own it.

To engineering: It's a thin presentation adapter over the Liberu Localization core — deliberately so. Locale resolution and persistence stay in the domain layer; the Livewire component just renders state and dispatches the switch. That separation is the reason to use it rather than hand-rolling a switcher inline: it keeps i18n out of our view layer and makes the component replaceable if we change our minds. Expect to restyle it fully and to read its source before shipping — the surface is small enough that a review is an hour, not a sprint. If the Liberu core contract does not match ours, the correct move is to lift the patterns and write our own; the code is short enough that this is not a loss.

Recommendation: Adopt as a time-boxed spike or a fork candidate, not as a strategic dependency. It is a low-cost accelerator for the switcher specifically, with the real i18n investment sitting in translation content and workflow, which this package does not address.