Lingua Laravel Package

Product Decisions This Supports

• Build vs. buy for locale plumbing — and the honest answer is usually "build." What Lingua actually delivers is narrow: a supported-locale list in config, Accept-Language negotiation, session persistence of a chosen locale, fallback resolution, and Blade/helper access to the active locale. The reference implementation in the docs is roughly ten lines of middleware plus a POST /locale/{locale} route. That is a decision input in itself: the buy option here saves a day, not a sprint.
• Separating "we support N languages" from "we have N languages of content." Lingua negotiates and switches locales; it does not create lang/it/*.php files, translate model attributes, or provide an editing UI. Framing localization this way forces the correct budget conversation: the code is cheap, the content and translation operations are the real cost and the real roadmap item.
• Roadmap sequencing for market expansion. Adding a locale becomes a config line plus translation files, which supports staging launches market-by-market rather than a single big-bang i18n release. It also clarifies what must be built separately for each new market (SEO/hreflang, localized URLs, content review).
• Scoping the language-switcher and user-preference feature. Concretely supports: header-based auto-detection, a persistent switcher for logged-in users (locale stored on the users table and re-applied at login), and per-request locale override. These are small, well-bounded features that can be scheduled and shipped independently of any content translation work.
• Dependency posture and platform risk. Two GitHub stars, a single maintainer, a last release of 2022-10-11, a pre-1.0 version (0.3.1), and an empty changelog are product signals, not engineering trivia. They drive an adopt / pilot / avoid call that should be made explicitly rather than inherited from a developer's composer require.
• Use cases where the capability genuinely fits: multi-market Laravel web apps needing automatic language detection and a switcher; localized marketing pages where the URL or session carries the locale; authenticated products where language preference should follow the user across devices. Use cases it does not fit: translated database content, translator workflows, machine translation, or CMS-style content operations.

When to Consider This Package

• Consider it if: you have a Laravel app, need header + session locale negotiation with a fallback, want the supported-locale list centralized in one config file, and you are comfortable pinning ^0.3 and treating the package as a starting point you own rather than a maintained dependency.
• Consider it as a design reference even if you don't adopt it. The documented patterns — middleware ordering after StartSession, one source of truth for locale, alias mapping for region variants like it-CH → it, Vary: Accept-Language, cache keys including locale, explicit locale on queued jobs and mailables, locale reset in tests — are worth copying into a homegrown implementation regardless of the vendor decision.
• Look elsewhere or build it yourself if: you want a maintained, community-backed solution (long-established localization packages have deeper ecosystems and active issue queues); if your need is translated model attributes (that is a different package category entirely — translatable-attribute libraries, not this one); if you need translation workflows, review/approval, or translator portals (that is a TMS problem); or if your localization is UI-strings-only, in which case Laravel's native lang files are sufficient and this adds a dependency for no gain.
• Hard diligence gates before any adoption:
  • Compatibility: last release predates current Laravel majors — verify it installs and its middleware signature works on your framework version.
  • Maintenance: no release in over three years and two stars means no bug-fix path. Assume you are the maintainer.
  • Changelog integrity: 0.3.1 has no stated changes; read the compare diff before assuming the upgrade is safe.
  • Scope check: despite the "translation manager" label, this negotiates locale; it does not manage translations. Confirm the team's expectation matches that, or you will ship a switcher and be surprised that the Italian page says pricing.title.
• Version caveat: at 0.x, treat 0.4 as potentially breaking no matter what the notes say. Any integration must sit behind a thin internal middleware/controller layer so a renamed method is a one-file fix.

How to Pitch It (Stakeholders)

To executives: This is a small Laravel package for language detection and switching — it recognizes a visitor's preferred language, remembers their choice, and falls back to a default. It does not translate anything; it routes people to the right existing translation. The honest assessment is that the capability is modest, comparable to a couple of days of our own work, and this particular package is a single-maintainer project with no release since 2022. My recommendation is not to take a dependency on it: we can implement the same behavior in-house in a short, well-understood effort, keep full ownership, and avoid an unsupported component in a customer-facing path. Use the package's documentation as our design checklist — middleware ordering, caching, and SEO handling are where these implementations actually break.

To engineering: Lingua covers locale negotiation and switching only — config-driven locale list, Accept-Language detection, session persistence, fallback, Blade/helper access. It does not touch model-attribute translation, translation files, or any editing surface. Given 0.3.1 with no stated changes, two stars, and no commits since October 2022, the recommendation is to treat it as a reference implementation rather than a dependency. If we build it ourselves, the acceptance criteria are: middleware registered on the web group after StartSession and before anything renders translated content; an explicit and documented negotiation order (user choice → session → header → fallback); region-variant alias mapping in exactly one place; locale-aware cache keys and a Vary: Accept-Language header on cacheable responses; explicit locale set on queued jobs and mailables; and a test suite that asserts negotiation, asserts persistence, and resets locale in tearDown(). If we do pilot the package instead, keep it behind a thin middleware/controller wrapper, pin ^0.3, and timebox the spike against our real routes so a swap is a one-file change.

Recommendation: Do not adopt. Build the negotiation layer in-house (~1–2 days) using Lingua's documented patterns as the specification, and reserve a formal adopt/replace review only if a maintained package with an active issue queue emerges that matches our requirements.