Languages Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on a language catalog. The package's entire scope is a Doctrine entity for languages (id, code, name, enabled flag) plus lookup wiring — roughly a small static reference table behind a trivial service. That's a domain where the PM decision usually resolves to build, because the artifact is ~200 rows of ISO 639-1 data and a repository class. This package is the evidence for that conclusion, not a candidate to install.
• Scoping the localization/i18n epic. Reading its public surface decomposes "manage languages" into the real sub-problems — code normalization, display names, native names, default-language fallback, per-language config, enabled/disabled filtering, and frontend/backend locale alignment. That decomposition is useful roadmap input even if the code is never touched.
• Roadmap sequencing: language switcher vs. translation pipeline. The bundle supplies only the language registry; it explicitly does not ship the data or the translations. That clarifies a dependency graph for planning: language registry → locale negotiation middleware → translation storage → admin CRUD. Each is a separate, schedulable slice, and none of them require this dependency.
• Legacy-stack viability. If the live question is "do we keep investing in this Symfony-era application," the repo is the data point: final release 2016-06-10, 2 stars, 0 dependents, read-only mirror of a monorepo subtree. That is ecosystem-decay evidence, not a feature evaluation.
• Vendor-risk triage and TCO. Composite score 0.01 against an opportunity score of 23.62 reads as "real, recurring problem space with no viable incumbent." The decision it supports is that the need is legitimate and the implementation is not the answer — which argues for an internal, owned solution rather than a fork line item.
• Dependency-policy precedent. It's a clean teaching case for an adoption checklist: framework fit, last-release date, dependent count, support channel, license for forking. Using it as a worked example in a dependency-standards doc has more durable value than any code in it.

One caveat that reframes all of the above: this is a Symfony bundle, not a Laravel package. There is no service provider, no publishable config, no Eloquent model, and its 2016-era Symfony 2/3 constraints will not resolve against Laravel 10/11's Symfony 6/7 transitive dependencies. Any "Laravel package" framing in the catalog is a mislabel. The PM-lens value here is entirely as a reference schema and a build-vs-buy argument.

When to Consider This Package

Consider it only in these narrow cases:

• You already run a Modera/Symfony 2.x–3.x application and it arrives transitively. Then the decision is "keep the lights on": pin it, wrap it, and put removal on the roadmap rather than an adoption decision.
• As read-only reference material for a native build. Skim Entity/Language.php and the DI extension to confirm your schema and field set before writing your own language service in Laravel. Zero dependency cost, roughly half a day, and it de-risks a design you'd otherwise guess at.
• As a specification input for locale semantics. Field ordering, default-language handling, and enabled filtering are the genuinely reusable parts; the PHP is not.

Look elsewhere — and you almost certainly will — when:

• The target stack is Laravel. Wrong framework. Consuming it means booting a Symfony bundle inside Laravel, registering Doctrine alongside Eloquent, and maintaining a bridge larger and riskier than the domain problem. Estimate: 1–3 weeks for fork-and-bridge versus 1–2 days to build native.
• You are on PHP 8.x or Symfony 6/7. A mid-2016 release predates modern typing, carries era-appropriate version constraints, and has no compatibility guarantees. Composer resolution failure is the single most likely failure mode; --ignore-platform-reqs buys a green build and an unverified runtime.
• You need a maintained dependency or a support path. 2 stars, 0 dependents, and a [READ-ONLY] subtree split mean no issue tracker destination, no Stack Overflow corpus, no upstream patch commitment. Issues and PRs have nowhere to go — you fork or you don't proceed.
• You need more than a static list. symfony/intl (or PHP's Intl / CLDR data, or umpirsky/language-list) supplies locale codes, display names, native names, and formatting, is actively maintained, and is already a transitive dependency in most stacks. Hand-maintaining ISO 639-1 names is the one thing you should not build.
• Security scanning gates your release pipeline. Abandoned transitive dependencies will be flagged, and you will own every patch.

Stated as plain criteria: existing Modera/Symfony codebase and no PHP upgrade path in the planning horizon and no appetite for a two-day internal replacement. If any one of those fails, skip it. In practice, at most one will hold.

How to Pitch It (Stakeholders)

To executives: Recommend we do not adopt this as a dependency — and flag the catalog entry as mislabeled, since it's a Symfony bundle rather than a Laravel package. The capability is small and static: a table of language codes, names, and an enabled flag, plus lookup helpers. We can reproduce the useful part internally in one to two engineering days, with no license questions, no framework bridge, and no foreign idioms in our codebase. Taking the package instead means inheriting a 2016 artifact with a read-only upstream, no release cadence, no support channel, and framework-version constraints that likely don't resolve on our stack — converting a small feature into a standing remediation line item. There is no upside to trade against that cost. On the plus side, this confirms a genuine ecosystem gap: the composite score is 0.01 against an opportunity score of 23.62, meaning the problem is real and recurring while the incumbent is not viable. That points at build, which is also where the cheaper path lies.

To engineering: Three findings up front. First, stack mismatch — it's a Symfony/Doctrine bundle with no service provider, no publishable config, and no Eloquent integration; consuming it means a Symfony bridge plus Doctrine alongside Eloquent, which is more work than the domain problem itself. Second, abandonment signals — final release June 2016, two stars, zero dependents, read-only subtree split, no upstream issue destination. Third, and most useful: treat the repository as a specification, not a dependency. Read Entity/Language.php and the DI extension, catalog the fields and uniqueness constraints and any default-language/fallback behavior, then implement natively: a languages migration (code unique, name, enabled), an Eloquent model, a cached LanguageRepository, and a SetLocale middleware doing Accept-Language negotiation. Source names from symfony/intl's Languages::getNames() instead of hand-maintaining the list. Ship it behind the same interface so a future swap is a container binding, not a rewrite. Budget one to two days for that path, versus one to three weeks for fork-and-bridge with materially higher ongoing ownership cost and a bus factor of one. If we already carry it transitively in a legacy service, scope a removal ticket, not an upgrade ticket — there is nothing to upgrade to.