Translating the text in a Laravel app is one problem, and allowing localized URLs is a different one.
You want in English and in Spanish, both real routes that resolve, appear in , and can be linked without knowing which language the visitor is on.
Doing it by hand means a route group per language, duplicated definitions, and locale detection glued on top.
Laralang does that half.
You declare a route once, list the languages, and it registers one real route per locale, names them, and keeps working.
Here is the whole thing, including the parts that are easy to get wrong.
Install Publishing is not optional in practice.
The config ships with a single locale, and both the middleware and the URL generator read the list from there, so until you fill it in your other languages are not recognised.
Two rules about prefixes that save a debugging session.
The unprefixed language is , not the first item in the array.
If your app runs in Spanish, is what makes live at the root and carry a prefix.
A value is the literal prefix, and without one the locale code is used.
A missing key, and an empty string all count as no value, so only the default language can end up at the root and two locales can never fight over the same URLs.
Declare a localized route Swap for .
The second argument is the locale list.
A bare locale reuses the base path, and gives that language its own URL.
That registers and .
Everything you chain applies to every generated route, so middleware, constraints and the rest work as usual.
There is a method per verb (, , , , , , ) plus .
Resources work too, and this is where a package like this usually gives up: Laravel's own resource registrar builds the routes, so , , , and keep working and apply to every language at once.
You get and , and both are named under their locale.
Route names carry the locale Every generated route is named , and there is no route registered under the bare name.
Be explicit when you need a specific language: And use the plain name everywhere else: That works because Laralang replaces Laravel's URL generator. looks for when the app locale is Spanish, and falls back to a route literally named if there is no localized one, which is what lets you mix and in the same app without thinking about it.
Active states in navigation keep working too, because understands the naming: Translated slugs, not just translated paths This is where it stops being cosmetic.
Route model binding accepts a different column per locale, so each language resolves its own slug: and hit the same controller with the same model, resolved through a different column.
And because picks the localized route for the current locale, builds the right URL with the right slug without any branching in your views.
A package that registers a single route with a dynamic locale prefix cannot express this: there is one definition, so there is one binding field.
Every URL of the current page, in one call Language switchers, tags and multi locale sitemaps are all the same question: what is this page called in the other languages? carries the current route parameters over, so dynamic segments survive, and it only returns the locales that actually have a route registered.
A page that exists in two of your three languages produces two links instead of a dead one.
Groups and prefixes The locale prefix always goes first, even inside a prefixed group: Detecting the locale Every route created by already carries the middleware, so the localized routes need no wiring.
The middlewares matter for everything else: plain routes, and any part of the app with no locale in the path. reads the locale from the route name or the URL prefix, and stores it in the session. applies whatever the session holds.
This is the one for an admin panel where the language is a user setting, not part of the URL. picks the best match from on first visit. combines them: prefix when there is one, session or browser when there is not.
They are idempotent, so stacking them is safe.
Two b