Laravel-Lang/lang: 128 Language Files For Laravel's Own UI Strings

The Gap Between Laravel's English Strings And A Second Locale

Laravel ships its own user-facing text: validation messages, pagination labels, password reset notices, and the human-readable names it prints for form fields. Those strings live in English language files inside the framework. The moment you add a second locale, the framework falls back to English for every one of them, and you are left translating messages you did not write and do not control. Laravel-Lang/lang exists to fill that gap. It packages translated copies of Laravel's own language files for 128 languages, covering Laravel Framework itself plus Jetstream, Fortify, Breeze, Cashier, Nova and Laravel UI. The audience is narrow and specific: teams running a Laravel application with a non-English locale who do not want to maintain framework translation files by hand as Laravel evolves. If your application is English-only, nothing here applies to you.

What Is Actually Inside The locales And source Directories

The repository layout separates generated data from the code that produces it. The locales directory holds the language files themselves, organised by locale, which is what ends up published into a Laravel application. The source directory holds the upstream inputs the project works from, and src contains the PHP package code. The docs directory backs the documentation site. That split matters when you evaluate maintenance cost: the translation content is data, and the package code is mostly tooling to publish and keep that data in sync. The README does not describe the internal pipeline beyond pointing at the documentation, so anyone who wants to understand how a locale is regenerated has to read the repository rather than the README. Tests live in tests, and the project runs its own CI workflow on the main branch, which is the mechanism that keeps 128 locales from silently drifting as Laravel changes its English source strings.

Installing Laravel-Lang/lang And Publishing Your First Locale

The README gives the install command in its banner and directs readers to the documentation page for detailed installation, so treat the steps below as the shape of the workflow rather than a complete guide. The package is installed with Composer as a development dependency:

composer require --dev laravel-lang/lang

After installation, the language files are published into your application's lang directory. The project provides an artisan publisher command for this; the exact command name and its flags are documented on the packages-lang page rather than in the README, so check there before running it. What you should see afterwards is a set of locale directories under lang, each containing the framework translation files for that language. From that point the files are yours: Laravel reads them like any other language file, and you can edit individual strings without touching the package.

The Publishing Step Is Also The Main Failure Mode

Because the language files are published into your application rather than read from the vendor directory, they become part of your source tree. That is a deliberate trade: you get editable strings, and you also get a directory that a future publish command can overwrite. If you have hand-edited a translated validation message and then re-run the publisher, the README does not document any rollback or merge behaviour, and the documentation page is the only place that could describe it. The practical consequence is that local edits need to live somewhere you can recover them, either in version control or in a separate override file. The second limitation is scope. This package translates Laravel's strings, not yours. Your own validation messages, model attribute names and flash messages still need their own translation files, and nothing in this repository generates them. Teams that expect a full localization solution will find they have solved roughly half the problem.

How This Differs From Laravel-Lang/common

The related searches around this project point frequently at Laravel-Lang/common, and the difference is worth stating plainly. Laravel-Lang/lang is the data: the raw translated language files for 128 locales. Laravel-Lang/common is the tooling layer that installs, updates and manages those translations inside a Laravel application, with commands for adding and updating locales. If you want the strings and are happy to publish them once, lang is enough. If you want to add a locale later, update translations after a Laravel upgrade, or remove locales you no longer support without manual file surgery, the common package is the one that automates those operations. Choosing lang alone means accepting that every future locale change is a manual publish and diff.

Maintenance Cadence, Licence And Upgrade Cost

The last push to the main branch was on 2026-09-20, and releases 15.36.0, 15.35.1 and 15.35.0 landed on 2026-09-20, 2026-09-14 and 2026-09-10 respectively. That is a fast release rhythm, and it reflects the underlying problem: Laravel adds and changes English strings, and 128 locales have to follow. For you the cost is a dependency that will want updating more often than most. The upside is that the translation data tracks the framework rather than freezing at whatever Laravel version you installed it with. The package is MIT licensed, which in practice means you can use, modify and redistribute it, including in commercial applications, provided the copyright notice and licence text are preserved. That is a summary of the licence identifier, not legal advice; read the LICENSE file and the licence page if the terms matter to your organisation.

Editorial conclusion

Adopt Laravel-Lang/lang if you ship a Laravel application in more than one language and do not want to hand-maintain validation and pagination strings. Skip it if your only locale is English, or if you already keep your own translation files under version control and do not want a dependency overwriting them. Before installing, check the docs page for the current publishing workflow, since the README itself only links out to it, and confirm which of the seven supported Laravel products you actually use so you do not publish strings for packages that are not in your composer.json.

Frequently asked questions

Official sources

1. Laravel-Lang/lang on GitHub
2. License: MIT
3. Project website
4. README
5. Releases