Language Switcher Laravel Package

Product Decisions This Supports

• Roadmap: admin-side localization readiness. This package answers a narrow but real question — "can our content editors switch the language context inside the Backpack admin without engineering help?" That unblocks a phased i18n rollout (admin UI locale first, content translation second) without committing to a heavier translation platform. New in 2.1.0: first-class support for Backpack v7, which means this unblock is available on our current admin major, not just the previous one.
• Build vs. buy (and "buy" here means adopt-and-vendor). The functional surface is small: a locale selector, session persistence, and a config file. In-house equivalents typically cost 1–3 dev days plus ongoing ownership. An MIT-licensed package from the Backpack core team is a legitimate shortcut — and 2.1.0 is a maintenance signal in favor of that framing: the core team shipped compatibility for a new admin major within a minor version bump, with no breaking changes and no config migration implied. The correct PM framing remains adopt with a fork plan, not adopt as a dependency you never look at — but the fork is now cheaper to justify because the maintainer has demonstrated they follow Backpack majors.
• Editor workflow and support-load reduction. If your operators currently ask engineering to "flip the site to French" or file tickets to verify a translation, this is a cheap lever on internal support cost. Success metric: translation-related internal tickets per release, and time-to-first-translation for a new locale.
• QA and content-verification use cases. A per-session locale switch lets QA and content reviewers validate translated strings in the real admin context rather than in a staging copy or a spreadsheet, which shortens the review loop on every localized release.
• Scope boundary decision. It solves switching the language context, not managing translations. Treat it as a UI affordance on top of whatever stores your translated strings (e.g. a translatable-fields approach in your models). Do not let it be sold internally as a translation management solution — that gap is where roadmap disappointment comes from. Nothing in 2.1.0 changes this: the release is compatibility and docs only.
• Discovery item to resolve before committing: confirm whether the switch drives admin UI locale only, or also the content-editing locale for translatable fields. Those are two different product promises and only one of them is likely delivered out of the box. This was already the gating spike, and 2.1.0 does not resolve it.
• Discovery item that 2.1.0 does resolve: whether the package is usable on our Backpack major. It now is, assuming we're on v7 (or on v6 via the 2.0.x line — verify whether 2.1.0 keeps v6 in its Composer constraints or is v7-only).

When to Consider This Package

Adopt when all of the following hold:

• You are already running Backpack for Laravel as your admin panel. This is a non-negotiable precondition — the value is entirely in fitting an existing admin shell.
• Your Backpack major is v7 (use 2.1.0) or v6 (use 2.1.0 if Composer constraints allow both, otherwise stay on 2.0.1). Check composer.json constraints before assuming a single 2.1.x line covers both — the release notes say "add support for v7," not "drop v6," but a minor bump is ambiguous enough to verify in five minutes rather than discover in CI.
• You need a session-scoped locale toggle for internal operators, not public-facing URL-prefixed localization (for the public site, a routing/localization package is the right tool).
• Your team is small enough that 1–3 dev days of avoided work is meaningful, and you accept vendoring/forking a low-star package as normal practice.
• You are comfortable that you, not the maintainer, are the primary owner of this code path going forward.

Look elsewhere when:

• You are not on Backpack. There is no partial-fit story here; the package is glue for one framework's UI.
• You need public-site locale routing, hreflang, or SEO-correct localized URLs. Different problem, different package.
• You need a translation workflow — string extraction, translator handoff, review states, coverage reporting, TMS integration (Lokalise, Crowdin, Phrase). A switcher is not a workflow.
• Governance requires demonstrated adoption. 2.1.0 does not change the adoption picture: low stars, near-zero dependents, low composite score. What it does change is maintenance responsiveness, which is a different axis. In regulated or long-horizon codebases the "write the ~150 lines yourself" option remains valid — though the argument for it is now weaker than it was, since the maintenance risk that motivated it has partially receded.
• You need per-field or side-by-side translation editing. That is a CRUD-field design decision, not a header dropdown.

Risk notes to carry into the decision:

• Version coupling to Backpack majors — materially reduced, not eliminated. 2.1.0 is evidence the maintainer tracks Backpack majors and ships compatibility in a minor bump. But it also means future major upgrades require this package to release first, putting a third party on your upgrade critical path. Vendoring removes that.
• Single-maintainer concentration — unchanged but now better evidenced. A core-team member is actively shipping. The realistic dormancy scenario (capability absorbed into Backpack core) remains, and is still survivable because the code is small.
• No breaking changes in 2.1.0. This is a safe, low-drama upgrade; no migration, no config or API changes described. Do not over-read it as a feature release — the product surface is identical to 2.0.x.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can give content editors the ability to switch languages inside our admin panel for zero license cost, using a small MIT-licensed add-on from the same team that builds our admin framework. It accelerates the localization phase of the roadmap by removing a recurring engineering dependency from the editorial workflow. It is now compatible with our current admin framework version, and the team behind the framework has just shipped that compatibility proactively — a good proxy for the maintenance risk we were underwriting. The risk remains contained and asymmetric: the component is a few hundred lines, so if the open-source project stalls we absorb the code in under a day. The decision to make is not "is this strategic" — it isn't — it's "do we want the localization milestone sooner at negligible cost and negligible downside." Recommendation: yes, with a vendoring plan.

To engineering (the honest version): This is a locale dropdown wired to session state, plus config, for Backpack admin panels. It is not a translation system, it does not touch your storage layer, and it does not solve public-site routing. Release 2.1.0 adds Backpack v7 support in a minor version bump — no breaking changes, docs-only otherwise — so the version-compatibility question that was previously a spike is largely closed, provided you confirm whether 2.1.0's Composer constraints cover v6 as well or are v7-only. That is a five-minute composer.json read, not a spike.

Treat the package as source code we are adopting, not a dependency we are trusting — fork it into the repo, pin it, and keep the diff reviewable. The one spike that remains from the original assessment is unchanged and still matters: verify whether it changes only the admin UI locale or also the content-editing locale for translatable fields. If that answer is wrong for us, we build the equivalent ourselves and the estimate is one to three days — which, given the code is this small and now has a version we can copy forward, is a genuinely low-cost fallback.

To the content/editorial team: You will get a language selector in the admin header that remembers your choice per session, so reviewing or entering content in a non-default language stops being an engineering request. What it will not do is manage translation status, coverage, or handoffs — that stays a separate conversation, and we should scope it separately rather than assume this covers it.