- What does caouecs/laravel-lang actually provide?
- It ships PHP array files for validation, auth, passwords, and pagination plus JSON attribute-name files for roughly 80 locales, all consumed by Laravel's native Translator. There is no service provider, middleware, or runtime hook, so it either works transparently or does nothing. It does not translate your domain content; that remains your team's responsibility.
- How do I install caouecs/laravel-lang in a Laravel app?
- Run composer require for the package line that matches your Laravel major, then copy or publish the locale directories into your app. On Laravel 8 and below the target is resources/lang; on Laravel 9 and later it is lang. For the modern line, laravel-lang/common adds php artisan lang:add {locale}. Verify the canonical Composer package name and supported version before pinning.
- Which Laravel versions does this package support?
- The legacy caouecs/laravel-lang line maps to the Laravel 6–8 era, while the modern laravel-lang packages track later majors up to Laravel 11. Support depends on the exact package line and release, so check the package's Laravel support matrix. The main compatibility break is Laravel 9 moving resources/lang to lang.
- Is caouecs/laravel-lang still maintained or should I use laravel-lang/common?
- caouecs/laravel-lang is the legacy name; the actively maintained line is laravel-lang/lang and laravel-lang/common. Depending on the legacy package is a supported-today, stranded-tomorrow path, so plan the rename now. Confirm the canonical package before pinning and migrate by swapping the package, re-adding locales, and diffing your overrides back in.
- Where do the translation files go in Laravel 9 and later?
- In Laravel 9 and later, translation files live in the lang directory at the project root instead of resources/lang. Adopt lang once and remove any custom path binding in AppServiceProvider. JSON attribute files merge into the same {locale}.json your app uses, so reconcile keys rather than overwriting them.
- How do I override or customize the shipped translations?
- Once you publish locale files into your repository, they are yours to edit. Keep your custom overrides, diff vendor strings against them on upgrades, and let custom values win while upstream fills gaps. Add a CI check for key parity between en and each supported locale.
- Why are some validation messages still showing in English?
- Validation messages evolve with Laravel releases, so a stale pin may lack keys that upstream added. Missing keys fail silently to the fallback locale, which is often why English still appears. Check locale and fallback_locale, update the package line, and compare key parity for the affected locale.
- Should I publish all ~80 locales to production?
- No, publishing all roughly 80 locales bloats the repository and increases review and QA burden. Ship only the locales you support commercially and are willing to QA. Removing unused locale directories and JSON files keeps the dependency bounded and the diffs readable.
- Will composer update refresh the translation files automatically?
- No. Once the files are published into your repository, composer update will not refresh them, which can create a false sense of currency. Document a sync cadence and an owner, then re-import target locales and diff custom overrides on each Laravel upgrade. Loading directly from vendor is possible but makes overrides and review harder.
- How do I test locale switching and what about database-backed translation alternatives?
- Set locale and fallback_locale in tests, then assert validation, auth, password reset, and pagination strings for each supported locale. Add a key-parity test between en and every shipped locale so missing translations fail CI. The package coexists with spatie/laravel-translation-loader or DB-backed translation because it is just PHP and JSON consumed by the native Translator.