Laravel Accept Language Middleware Laravel Package

Product Decisions This Supports

• Market launch sequencing. The package's config file is effectively a product lever: the supported-locale list is the list of markets you can serve. Adding a locale becomes a config + translation-file change rather than a controller refactor, so the PM can decouple "which languages we ship in Q3" from an engineering project. That materially shortens the lead time between a market decision and a market launch.
• Localized URL strategy (SEO and shareability). Choosing example.com/fr/... over cookie-only or header-only detection is a product decision with SEO, cacheability, and analytics consequences. This package makes header detection cheap as a fallback layer underneath a URL-first strategy, which is the pattern most teams converge on. It does not replace the decision — it removes the excuse for not doing it.
• API and partner-surface negotiation. For multilingual APIs, whether clients can request content in their own language is a product capability, not an implementation detail. Quality-value parsing and graceful fallback mean a partner integration doesn't break when a client sends a slightly odd header. That's a support-cost argument as much as a technical one.
• Build vs buy, resolved cheaply. The scope is narrow enough that building it is roughly a day of engineering — but that day is spent in the locale-resolution path, which is user-visible and hard to trace when wrong. Buying a ~10KB MIT-licensed middleware and spending the saved day on verification and test coverage is the better trade. The honest framing: this is a decision you should make quickly and not revisit, not a strategic platform choice.
• Where it should not anchor a roadmap. It handles one hop: request header → App::setLocale. It does not do translation content management, review workflows, RTL layout, currency/date formats, database content localization, hreflang emission, or CDN Vary handling. Treating it as an i18n strategy is the most likely PM-level mistake here.

When to Consider This Package

Adopt when:

• You already have (or are about to have) more than one shipped locale and are currently duplicating locale-detection logic across controllers or a base controller.
• Your URL scheme will carry locale, and you want header negotiation to handle the entry point (example.com/ landing, deep links from search or email that lack a locale segment).
• You serve multilingual API responses, or partner clients send Accept-Language you currently ignore.
• You can live with a thin dependency behind your own resolver boundary, and you have a locale test matrix to run against it.

Look elsewhere or build in-house when:

• You need more than header parsing. Wildcard variants, region normalisation (pt-BR vs pt_BR vs pt-br), und/zxx handling, and weighted-wildcard semantics are not fully covered. If correct RFC 7231 content negotiation is a requirement (e.g., a public API with contractual behaviour), you want a fuller negotiation library or a custom resolver.
• Your locale truth lives elsewhere. Session-pinned preference, authenticated user profile, tenant configuration, or geo-IP should outrank the header. This package is a link in the chain, not the chain.
• Supply-chain posture is strict. 16 stars, a single maintainer, and a patch release (3.0.1) that changed behaviour without a minor bump are the three facts that matter. If your dependency policy requires active multi-maintainer projects for anything in the request path, this fails on paper. The mitigation is cheap and worth taking: it's MIT and tiny, so vendor it or wrap it behind an interface you own.
• You only support one locale today. You will pay review, upgrade, and test-matrix costs for a capability nobody uses yet.

Default recommendation: adopt behind an owned interface, pin ^3.0, and treat the package as replaceable. It is small enough that the exit cost is near zero — which is exactly why the decision doesn't deserve a long debate.

How to Pitch It (Stakeholders)

For executives — one paragraph. We can serve visitors in their own language from day one of a market launch instead of waiting on a routing or personalization project. This is a small, free, open-source component that reads the language the browser already sends and applies it automatically. Cost is roughly a day of engineering plus a day of QA; the benefit is that launching a new language becomes a content task rather than a software project, and multilingual API clients stop getting English by default. The risk is proportionate: single maintainer, low adoption, so we wrap it behind our own boundary and can replace it in under a day if needed. Decision needed: approve adoption as a thin utility, not as our localization strategy.

For engineering — the short version. Standard Laravel package: Composer, service provider, publishable config listing supported locales and a fallback. Registers as global or route middleware, parses weighted Accept-Language, sets the locale per request. 3.0.1 adds a guard so * is never assigned as the application locale — verify that path explicitly, since * is a legitimate header value from crawlers and privacy browsers, and previously produced app()->getLocale() === '*', broken route() output, and missing translation keys.

Three things we own regardless of the package:

1. The resolution chain — route segment → user/session preference → Accept-Language → app fallback → config default, defined in exactly one place.
2. A regression test matrix — bare *, *, fr;q=0.8, missing header, ?locale=*, and an unsupported locale. Assert the resulting locale, not the implementation.
3. Cache correctness — emit Vary: Accept-Language on any header-negotiated route, and re-run the matrix under config:cache and Octane, where locale state can leak across requests.

Success metrics to watch post-launch: share of sessions served in a non-default locale; support tickets tagged "wrong language"; bounce rate on locale-redirect landing pages; and locale-mismatch reports from API partners. If "wrong language" tickets don't fall, the problem is almost always session precedence or a stale cached locale list — not this middleware.