Languagechooser Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for a language switcher. This package clarifies that a locale chooser is a small, well-understood surface — a rendered list of locales, a session/URL write, and a redirect — not a platform capability worth a dependency. That makes the decision "build it in-house (~1–3 dev days)" rather than "adopt a library."
• Stack direction. The package is a Symfony bundle, not a Laravel package. If the roadmap assumes Laravel, this is immediately out of scope and should be closed as a candidate rather than parked. If there are legacy Symfony 2.x/Kunstmaan CMS properties in the portfolio, it becomes a maintenance-vs-migrate question for those properties only.
• Localization scope. It supports a narrow slice of i18n — locale selection and redirect. It does not address translation management, hreflang/SEO metadata, region/currency, content fallback, or per-locale routing strategy. Product should treat those as separate roadmap items, not assume a "language chooser" bundles them.
• Multi-market launch sequencing. A chooser is a launch-blocker for the second locale, so it belongs in the MVP scope for market #2 — but it's cheap enough that it shouldn't drive architecture or vendor review time.
• Maintenance liability budget. With a last release in May 2014, 6 stars, and 0 dependents, adopting this adds an unmaintained code path with no upstream patch stream. The decision this informs is whether the team is willing to own a vendored fork indefinitely — for most teams the answer is no.

When to Consider This Package

Consider it only when all of the following hold:

• The project is an existing Symfony 2.x application already on the Kunstmaan CMS stack (NodeBundle/SiteBundle), where this bundle's integration assumptions are already satisfied.
• The runtime is pinned to an era-appropriate PHP version and there is no near-term upgrade path being funded.
• The requirement is genuinely minimal — render available locales, switch, redirect — and no SEO/hreflang, geo-routing, or translation-workflow requirements exist.
• The team accepts full ownership: no upstream fixes, no security patches, no community answers.

Look elsewhere (or build) when any of these are true:

• The stack is Laravel or any non-Symfony framework — this is a hard stop; there is no port and none is coming.
• You need PHP 8 / modern Symfony support, or you have a dependency policy requiring maintained packages. An 11-year-old bundle will not pass a security or license review in most organizations.
• You need real i18n: hreflang and canonical strategy, locale-aware routing/slugs, geolocation-based suggestion, translation management integration, or per-locale content governance.
• You want community support signal. Zero dependents means no one has stress-tested this in the wild; you would be the only operator.
• SEO/discovery is a KPI for the second market — a basic chooser with redirects can create duplicate-content and crawl-budget problems if built naively, and this package has no opinion on that.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Build a small in-house chooser (or use framework-native locale switching).

For executives: This is a 2014 Symfony bundle with no releases in over a decade, six GitHub stars, and zero dependent projects. Adopting it would add an unmaintained component to our codebase in exchange for saving roughly one to three engineering days. The asymmetry is bad: trivial savings against indefinite ownership of unpatched code, plus a guaranteed blocker at our next PHP or framework upgrade. A language switcher is a small, well-understood UI and routing concern — we should own those ~200 lines rather than inherit someone else's abandoned ones.

For engineering: It's a Symfony bundle, so it's a non-starter on our Laravel services. Even on Symfony, the effort it saves is a controller, a Twig partial, and session/redirect handling — all of which we'd rewrite anyway to meet SEO requirements (hreflang, canonical URLs, locale-prefixed routing) that the bundle doesn't cover. Use the framework's native locale handling plus our own route/URL strategy; budget half a sprint including tests.

Decision requested: Close this as an evaluated-and-rejected candidate, and log "language switcher" as an in-house build item scoped to the market-#2 launch, with SEO requirements attached.