Locale Bundle Laravel Package

Product Decisions This Supports

• Whether to commit to multilingual UX in the next release. Locale negotiation, per-user language persistence, and a language switcher are table-stakes for i18n; this package is one candidate for the plumbing behind that decision.
• Build vs. buy vs. vendor for locale handling. The functional surface here is small (detect preferred locale from the request, persist a user's locale, set it on the request). That makes "write ~100 lines against framework primitives" a credible alternative to taking on a dependency, and this assessment should force that comparison explicitly.
• Dependency inventory and vendor-risk posture. Zero stars, zero dependents, and a last release in December 2020 mean no community safety net and no upstream maintenance signal. This feeds directly into SBOM/third-party review and any "no unmaintained dependencies" policy.
• Framework strategy alignment. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle. If the roadmap includes Laravel or framework-agnostic PHP services, it is not reusable there — a decision input for standardization on one framework's i18n primitives.
• Inherited-codebase triage. For a legacy Symfony application where this is already installed, the decision is contain-and-replace versus fork-and-own, not greenfield adoption.
• Roadmap sequencing of i18n foundation vs. content translation tooling. This package covers request-locale mechanics only; it does not address translation management, string extraction, or localized routing. Adopting it does not advance those roadmap items.

When to Consider This Package

Consider it when:

• The application is a Symfony app (roughly the Symfony 3/4/5 era it was built for) and the requirement is genuinely narrow: read Accept-Language, store a locale preference on the user, and apply it per request.
• You are already running it and need a documented path to keep it alive — the MIT license permits forking and vendoring, and the small surface makes that tractable.
• You have engineering capacity to own the code indefinitely: pin it, read it, and treat the fork as first-party. Budget on the order of a day to vendor, test, and document.
• License posture matters and permissive terms are required — MIT is clean for commercial and closed-source use.

Look elsewhere when:

• The target is Laravel or any non-Symfony framework. Framework-native locale handling (App::setLocale, middleware) and mature packages such as mcamara/laravel-localization are better supported and actually maintained.
• You need active maintenance, security patching, or a responsive maintainer — five years without a release is disqualifying for anything customer-facing and long-lived.
• You need URL-based localized routing, translation workflow tooling, or content translation management (Phrase, Lokalise, Crowdin). This bundle does not do that job.
• Modern Symfony is in play: the framework's own LocaleListener and Request::getPreferredLanguage() cover much of this ground, which may render the package redundant.
• Your dependency policy requires community validation. Zero stars and zero dependents is not a signal of quality either way — it is an absence of signal, which for a PM is its own risk.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed component that handles locale detection and per-user language preference in Symfony applications. It costs nothing to license and carries no legal exposure. The real cost is ownership: it has had no release since 2020, no stars, and no downstream dependents, so there is no community maintaining it. My recommendation is not to adopt it as a new strategic dependency. Where it already exists, treat it as contain and replace: pin the version, assign an owner, and plan to migrate to framework-native locale handling. The financial risk is negligible; the risk is quiet accumulation of unmaintained code in the critical path of a customer-visible feature.

For engineering: The functional surface is narrow enough that a first-party implementation against Symfony's LocaleListener and getPreferredLanguage() is likely less total effort than adopting, validating, and eventually migrating off this bundle. If we do keep it, vendor it into the repo, pin the version, add tests around locale negotiation and fallback behavior, and document it as forked. Note the framework mismatch up front — this is a Symfony bundle, so it does nothing for Laravel services and should not be counted toward cross-framework i18n standardization.

Recommendation: Do not add as a new dependency. If present, contain and schedule replacement. Revisit only if the alternative is building locale negotiation from scratch in a Symfony app and the team explicitly accepts long-term ownership.