Localeswitcher Widget Laravel Package

Product Decisions This Supports

• Localization roadmap and market sequencing. A locale switcher is a public commitment that the product has genuinely parallel content in multiple languages. Adopting one forces the honest question: are we shipping translated content, or a language dropdown veneer over an English app? Answer that first; the widget is downstream of it.
• Build vs. buy on commodity UI. The visible capability here is a list of links that swaps a locale segment in the current URL. That is a Blade partial plus route resolution — roughly 40–80 lines, under a sprint for one engineer. The existence of a packaged version is useful prior art and evidence the scope is small, which argues for owning the markup, analytics hooks, and accessibility behavior ourselves.
• Platform and framework lock-in. This is a Victoire DCMS bundle on Symfony, not a Laravel package, despite the description. Adopting it is a CMS-and-framework decision, not a language-switcher decision. For a Laravel product it is architecturally incompatible; it should inform the stack debate, not the UI backlog.
• i18n UX scoping. Informs backlog items: switcher placement, browser-language detection, persistence of the visitor's choice, SEO hreflang emission, and analytics on language preference. A switcher widget alone delivers none of those — no hreflang, no translation workflow, no content fallback.
• Use cases served by the pattern: multi-market content sites, public-sector or regulated sites that require an explicit language choice, and editor-placeable language blocks in page builders. The pattern is reusable; the artifact is not.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running Victoire DCMS on Symfony and using its widget/page-builder registry.
• You want an editor-configurable language block placed in a page zone without developer involvement, and you'd rather not write a custom widget.
• You have verified compatibility against your pinned Symfony and Victoire versions and are prepared to fork and own an unmaintained bundle.
• You accept that localization routing (/en/... prefixes, subdomains), hreflang, and content fallback are separate work you will build yourself.

Look elsewhere — or build in-house — when:

• Your stack is Laravel or a non-Victoire Symfony app. The bundle requires a Symfony kernel and Victoire's DI and widget entity model; Composer may autoload it, but nothing will call it. This is a hard mismatch, not an inconvenience.
• You need hreflang automation, geo/IP detection, translation management, or fallback logic — none are provided.
• Supply-chain and maintenance risk matter. Zero stars, zero dependents, zero downstream validation, dormant upstream on EOL Symfony 3.x / PHP 7.0–7.2. We would be the sole consumer and de facto maintainer of someone else's abandoned code.
• You require accessibility guarantees — keyboard navigation, screen-reader labeling, correct lang attributes. Own the markup.
• The requirement is simply a header/footer switcher rather than editor-placeable placement — true widget semantics aren't needed, so the bundle's only real value doesn't apply.

How to Pitch It (Stakeholders)

For executives: This is a small UI component from a niche, dormant CMS ecosystem with effectively zero adoption. The capability — letting a visitor pick a language — is trivial and cheap to build ourselves, and we'd control quality. Recommendation: do not adopt it as a dependency. Treat it as prior art, and spend the leadership attention on the real decision: whether we are investing in genuine multi-language content capability, because a switcher without translated content damages credibility more than it helps.

For engineering: It's a Symfony/Victoire bundle, not a Laravel package — on our stack it is inert, and Composer resolution will fail on symfony/* constraints. There are no maintainers, no dependents, and no security posture; adopting it makes us the fork owner for a feature worth about a day. Reproducing the behavior natively — a Blade component reading config('app.locales'), resolving the current route and parameters, preserving the query string, and emitting hreflang links — gives us control over routing model, analytics events, cache behavior, and accessibility. Sequence it as one sprint item, not a dependency evaluation.

Risk framing: The asymmetry is clearly against adoption. Minimal time saved versus permanent ownership of abandoned code that anchors the platform to an EOL Symfony generation and blocks PHP 8 and framework upgrades. Ship the native component and revisit only if a Victoire-based Symfony estate is confirmed as the real target — in which case scope the work honestly as "adopt an unmaintained bundle we now own," not "integrate a package."