I18N Routing Bundle Laravel Package

Product Decisions This Supports

• Market-expansion sequencing. Launching a new locale (e.g. /fr/, /de/) is gated on URL architecture: locale-prefixed, shareable, indexable URLs. This package illustrates the pattern worth deciding on — automatic locale prefixes, translated path segments, per-locale route generation, and locale detection with a default fallback — regardless of whether the code itself is used.
• Build vs. buy (verdict: build). The capability is roughly 1–2 engineering days natively in Laravel and is largely supported out of the box today. Treat this repository as a design reference, not a procurement candidate.
• URL architecture as a product decision. Localized path prefixes vs. query-string locale (?lang=fr) vs. subdomains. This choice drives organic acquisition, analytics segmentation, hreflang implementation, canonical/duplicate-content handling, and campaign link management — decisions a PM owns, not just engineering.
• Scope negotiation on translation quality. Do translated path segments (/de/produkte) justify the ongoing translation-operations cost, or is a locale prefix on English slugs (/de/products) an acceptable v1? A real trade-off between SEO/brand trust and translation throughput.
• Stack-fit correction. This is a Symfony bundle (a fork of schmittjoh/JMSI18nRoutingBundle), not a Laravel package — no service provider, no middleware, no Laravel route-loader integration. If the roadmap is Laravel, this is out of scope as a dependency; the relevant decision is native {locale} route groups plus middleware (or a maintained alternative like mcamara/laravel-localization).

When to Consider This Package

Consider it only in these narrow cases:

• You maintain a legacy Symfony application already coupled to the JMS ecosystem, frozen on a PHP/Symfony version from the bundle's active era, and cannot allocate work to migrate routing.
• You need a reference implementation or porting source for locale-aware route semantics — the router-decorator approach, per-locale route cloning, route name patterns ({name}.{locale}), and strategies like prefix_except_default are worth reading before writing a spec.
• You want prior art on the problem shape (translated paths via translation catalogs, locale fallbacks, opt-in route internationalization) to pressure-test your own design.

Look elsewhere — decisively — when:

• Any new build. Archived, 1 star, 0 dependents, package score 0.0825. No maintenance path, no security patching, no compatibility guarantee with current PHP versions, no community to escalate to. Archived status alone is a hard stop for a production dependency; pinning an exact commit doesn't fix the absence of upstream remediation.
• You are on Laravel, which this package does not serve. Native route groups with a {locale} prefix plus a single locale-resolution middleware delivers the same outcome with fewer dependencies.
• You are on modern Symfony, where the routing component has supported localized route paths natively since 4.1; a small _locale requirement plus prefix configuration covers most cases.
• The requirement is content translation, not URL translation. Different problem; route localization doesn't solve it and shouldn't be bundled into that decision.
• Your SEO acceptance criteria are strict (canonicals, hreflang, redirect behavior, sitemap generation). An unmaintained router decorator is the wrong place to carry that risk.

How to Pitch It (Stakeholders)

To executives: The underlying question — should we ship locale-specific URLs as we expand into new markets — is worth answering yes to, because it is a measurable SEO and conversion lever and a prerequisite for launching each new language. This specific package is not the answer: it is an abandoned, single-maintainer Symfony component with effectively zero adoption, and it isn't even built for our Laravel stack. Adopting it would create an unpatchable dependency and a future migration liability for a capability we can build in a couple of days.

To engineering: Treat this as a design reference only. Recommendation is to implement locale-prefixed routing natively — configurable locale set, {locale} route groups, one locale-resolution middleware, route name helpers that accept an explicit locale (for language switchers, hreflang, and sitemaps), translated path segments only where SEO justifies the translation cost, correct canonical/hreflang output, and a deliberate redirect strategy for the default locale. Watch the known scaling effects: routes multiply by locale count, which touches route-cache size and warmup, URL-generation tests, redirect chains, and CDN cache keys. Effort is small and fully within our control.

Bottom line: the pattern is worth adopting; the package is not. Do not add a dependency here — replicate the behavior in-house and keep the archive as documentation of the problem, not as a component of our product.