Laravel Tongue Laravel Package

Product Decisions This Supports

• Multi-market expansion: localizedRoutes() gives each locale its own translated URL (e.g. /bienvenue vs /welcome), so launching a new country/language becomes a routing configuration decision rather than a bespoke engineering project per market.
• SEO and discoverability: Native, stable per-locale paths are exactly what search engines and regional marketing teams need; translated slugs are a ranking and click-through lever, not just a UX nicety.
• Production readiness as a gate: Route caching and Octane compatibility mean localization no longer blocks a performance or infrastructure roadmap. This is the release that moves the package from "nice demo" to "safe for high-traffic production."
• Conversion-funnel integrity: speaks-tongue redirects with 307 for form requests, preserving method and payload. That is the difference between "localization broke our signup form" and "localization shipped without incident" — a real risk item on any checkout, onboarding, or lead-gen funnel.
• Build vs. buy: The package handles the routing and request-resolution layer of i18n. That lets the team avoid building locale-aware routing, slug translation, redirect handling, and route-model binding ordering in-house — typically weeks of work with subtle edge cases.
• Roadmap sequencing input: Translated route-model binding now resolves before bindings fail, which removes a class of 404s from localized content pages. That unblocks content-heavy localized surfaces (CMS pages, product catalogs, docs) that would otherwise need custom resolution logic.

When to Consider This Package

Adopt when:

• The product is on Laravel and multi-locale is on the roadmap (or already in flight).
• Translated URL slugs matter — SEO-driven marketing, content sites, or any product where /fr/bienvenue outperforms /fr/welcome.
• The team runs or plans to run route caching or Laravel Octane. Prior to 6.1.0, translated routes were a known obstacle here; that friction is now resolved.
• You need locale-aware redirects that don't destroy POST data (forms, auth flows, checkout).
• You want route-model binding to work against translated slugs per request locale without custom middleware wrangling.

Look elsewhere or supplement when:

• The stack isn't Laravel — this is framework-coupled by design.
• You need a translation management platform (string workflow, translator collaboration, TMS integrations). This package is routing/request resolution, not a CMS or TMS — expect to pair it with something like Lokalise or Crowdin.
• Localization needs are trivial (one language, or locale purely via a header with no URL strategy). The overhead isn't justified.
• You require per-locale domain strategies beyond what the package's configuration supports, or heavy A/B testing on URL structure — validate fit before committing.
• The team cannot absorb the middleware-ordering model (detects-tongue / speaks-tongue running before SubstituteBindings). It's well-designed, but it is an architectural contract worth understanding, not just installing.

How to Pitch It (Stakeholders)

For executives: Localization is a growth lever, and the routing layer is where most localization projects quietly stall. The 6.1.0 release removes the two blockers that typically force a "we'll do i18n next quarter" deferral — it now works with production performance infrastructure (route caching and Octane) and it doesn't break forms during locale redirects. Net effect: entering a new market becomes a configuration and content exercise, not a platform rebuild. The build-vs-buy math favors adopting this over hand-rolling locale routing.

For engineering: This release closes the production-readiness gap. localizedRoutes() registers translated routes once per locale, making route:cache and Octane viable with localized URLs — previously a hard blocker. The speaks-tongue middleware redirects to the current locale's path and returns 307 on form requests, preserving method and body. Middleware ordering now places both detects-tongue and speaks-tongue before SubstituteBindings, so route-model binding resolves translated slugs in the request's locale and redirects fire before a binding can fail. dialect()->redirect() now accepts an explicit status code for cases where 307 isn't right. Low integration risk, clear upgrade path, and it eliminates a meaningful amount of custom routing code we'd otherwise own and maintain.