- How do I install laravel-translations-checker?
- Install it as a dev dependency with composer require --dev larswiegers/laravel-translations-checker. Laravel's package discovery picks it up automatically, so no manual service provider registration is needed. Then run php artisan translations:check to scan your language files and see which keys are missing per locale. Because it is dev-only, it adds no runtime surface to your application.
- Does laravel-translations-checker support Laravel 11 and Laravel 12?
- Yes. The changelog and release notes indicate support for Laravel 10 through 12 on PHP 8.0 and above, including recent Laravel 12 compatibility work. That covers the large majority of actively maintained applications. As always, run the command once in your own project or CI pipeline to confirm behaviour on your exact version.
- How do I exclude vendor or package language files from the translations check?
- Pass --excludedDirectories=lang/vendor on the command line, or set 'excluded_directories' => ['lang/vendor'] in the translation-checker config file. Package-published language files and nested package namespaces are the usual source of noise, so tune this list early. Also exclude non-translation artifacts such as macOS resource fork files, otherwise you will get false alarms that erode trust in the check.
- Does the translations:check command return a non-zero exit code for CI pipelines?
- Exit-code semantics are not documented in the README, which only shows free-form text output. If you want to use this as a hard CI gate rather than an advisory log, verify the non-zero exit status empirically in a throwaway pipeline stage first. Do not write it into a definition of done until you have confirmed the behaviour and that it is stable across the versions you support.
- Can I run the checker against a custom translations directory?
- Yes. Use the --directory option, for example php artisan translations:check --directory=resources/lang, if your language files live somewhere unusual. This makes it usable for projects that keep translations outside the default lang or resources/lang path. Directory and exclusion options are also available as config values so CI runs stay short and readable.
- Does it find translation keys used in code that no language file defines?
- No. The package compares locale files against each other, so it answers whether locale B is missing keys that locale A has, not whether your code references a key that no locale defines. It does not parse application code for __(), @lang, or Lang::get() calls. It also does not report unused keys, so correct expectations matter before stakeholders read a green run as full coverage.
- How do I exclude specific languages from the translations check?
- Open the translation-checker config file and add the language codes you want to skip to the exclude_languages field, for example ["en", "fr", "es"]. This is useful for partially translated locales or placeholder languages you do not want to fail the check. Treat it as a permanent, reviewed decision rather than a quick suppression, and assign an owner so the list does not quietly rot.
- Can I limit the check to only PHP or JSON translation files?
- Yes, use the --excludedFileExtensions option so only the file types you care about, such as php or json, are checked. The same behaviour is available through the package configuration. This helps when your project mixes formats or vendors ship files in extensions you do not maintain. Filtering extensions also reduces false alarms and keeps the command fast.
- Does it compare translation values, placeholders, or only key presence?
- Documented behaviour is key-set comparison across locales, so a green run means the key sets are symmetric, not that the translations are correct. Placeholder mismatches, empty values, pluralization variants, and dynamic keys such as __($keyFromDb) are not demonstrated as detected. Review those cases separately if translation quality, not just parity, is what you need to enforce.
- Is laravel-translations-checker actively maintained, and what are the alternatives?
- It is a single-maintainer MIT package with few recorded dependents, so ecosystem scrutiny is low and recent Laravel version support has partly come from outside contributors. The blast radius of abandonment is small: you delete a dev dependency and lose one check, so it sits comfortably in acceptable-with-a-fallback territory. If you need code-usage or placeholder analysis, pair it with a static-analysis approach, since this package only compares language files against each other.