Laravel Lang Laravel Package

Getting Started

overtrue/laravel-lang ships ready-made translations for Laravel's framework strings (validation.php, auth.php, passwords.php, pagination.php) in dozens of locales, so you don't hand-translate "The email field is required" into every language you support.

composer require overtrue/laravel-lang
php artisan lang:publish

As of 6.0.3 the publish target is chosen per framework version: on Laravel 9+ files land in lang/, on older releases in resources/lang/. That means the same command works whether you're on an LTS or a current app, which matters if you maintain several projects on the same toolchain.

First things to look at after publishing:

1. The directory that just appeared — lang/{locale}/ (or resources/lang/{locale}/). Confirm the folder names, because they must match the values you put in config('app.locale') exactly.
2. lang/{locale}/validation.php — the file you'll actually touch most; it contains both the rule messages and the attributes array used to humanize field names.
3. config/app.php — set locale and fallback_locale. A common first use case: a zh_CN or ja app where you set APP_LOCALE=zh_CN and immediately get localized validation errors for free.

Implementation Patterns

Publish, then commit the files you use. The package is a one-shot scaffolding tool, not a runtime translator. Publish everything, keep only the locales you actually ship in version control, and delete the rest so the repo doesn't carry 60 unused directories. Committing the files makes deployments deterministic and lets you review translation changes in diffs.

Per-request locale negotiation. Leave fallback_locale as en and switch at runtime with middleware:

public function handle($request, Closure $next)
{
    app()->setLocale($request->user()->locale ?? $request->getPreferredLanguage(['en', 'zh_CN']));
    return $next($request);
}

Because the files are plain PHP arrays, this is just a directory lookup — no cache warmup needed.

Keep your app strings separate from framework strings. Framework files get replaced when you re-publish after a Laravel upgrade; your own copy would be lost. Put app-specific text in lang/{locale}.json (JSON translations) or in your own lang/{locale}/app.php. That way a forced re-publish only clobbers the framework files, which is what you want.

Deployment integration. For container builds, add the publish step to your deploy script after composer install only if you aren't committing the files. If you are committing them, don't run publish in production — it's a build-time concern and a surprising source of "why did the site text change after deploy" incidents.

Attribute humanization. The most valuable edit most teams make is the attributes array in validation.php:

'attributes' => [
    'email' => '电子邮箱',
    'password' => '密码',
],

This turns "The email field is required" into "电子邮箱 不能为空" without touching a single validator rule.

Gotchas and Tips

The Laravel 9 path change is the big one in 6.0.3. If you previously published to resources/lang on a Laravel 9 app, that directory still exists and Laravel 9 will use it, silently ignoring the new lang/ output. Two directories on disk, one of them dead, and no error message. Delete the stale directory (or your custom langPath) before re-publishing, and check app()->langPath() if things look wrong.

Publishing overwrites. lang:publish writes files; any hand-edited framework string in that directory is at risk on re-run. Back up customizations or, better, keep them out of the framework files entirely.

Re-publish after framework upgrades. New Laravel releases add validation messages. A stale published validation.php lacks them, so those keys fall through to fallback_locale and you get a mix of languages in one form. Re-publish with whatever force flag the command exposes and diff the result.

Locale code format. Directory names use underscores (zh_CN, pt_BR), not hyphens. If your APP_LOCALE is zh-CN, Laravel finds nothing and quietly serves English via the fallback — no exception, no warning. This is the single most common "translations don't work" cause.

Missing keys fail silently. There's no exception for an untranslated key, just the fallback. If you need coverage guarantees, write a test that loads each supported locale's validation.php and asserts the key set matches the en baseline.

Caching. Translations themselves aren't cached, but if you make locale decisions in a config file or custom provider, remember php artisan config:cache during deploy — a cached config will hide an env change and make locale switching look broken.

Extension points are shallow, deliberately. There's no runtime translation API here. If you need dynamic, database-backed translations, this package isn't it — use it as the framework-string baseline and layer a separate solution (spatie/laravel-translation-loader or similar) for editable content. Mixing the two in the same lang/ directory is a reliable way to confuse yourself later.

Contributing back is cheap. Each locale is one folder of four small arrays. If a translation is wrong for your language, a PR against the package is usually faster than maintaining a local override — and 6.0.3 shows the maintainers are actively merging community fixes (both PRs in this release are first-time contributors).