- What is simonecerruti/laravel-translation-audit used for?
- It is a Laravel package for auditing your application's translation files. It helps surface missing, unused, or inconsistent translation keys across locales using Artisan commands. It is most useful for Laravel apps that rely on Laravel's translator and the __() or @lang helpers and need to keep large locale files organized.
- How do I install laravel-translation-audit in a Laravel app?
- Install it with Composer using composer require simonecerruti/laravel-translation-audit, then review the README for any required configuration publishing steps. The package is Laravel-native and exposes its auditing features through Artisan commands. Start with a non-production branch and run the read-only audit commands before adding any cleanup workflow.
- Which Laravel and PHP versions are supported?
- The provided overview does not list exact Laravel and PHP version constraints, so check the package README and composer.json before adopting it. Because the package is pre-1.0, validate it against the oldest and newest Laravel and PHP versions your team actually supports. Pin the package version in composer.json and test upgrades deliberately.
- Can I use it in CI to fail builds on missing translations?
- The package is Artisan-command based and fits naturally into GitHub Actions, GitLab CI, Jenkins, or similar pipelines. Confirm in the README whether your package version provides machine-readable output and non-zero exit codes for missing or unused keys. A safe rollout is to publish a baseline first, then add a CI job with a defined threshold or allowlist.
- How does it detect dynamic translation keys like __('payments.'.$method)?
- Version 0.12.7 improves dynamic-key detection by resolving keys through Laravel's translator instead of comparing only raw locale-file keys. This makes the audit more useful in real Laravel codebases where dynamic translation keys are common. Some highly dynamic or runtime-dependent keys may still require allowlists or manual review.
- Is translation:purge-unused safe to run?
- Treat translation:purge-unused as a mutating command because it can change or remove locale file entries. Review the diff before committing, keep locale files under version control for rollback, and check the README for dry-run, backup, or diff-review support in your version. Introduce it only after a read-only audit and triage workflow are established.
- Why did new missing keys appear after upgrading to v0.12.7?
- Version 0.12.7 changes reporting behavior rather than only fixing internal code. Nested keys such as validation.password, Laravel-provided keys such as validation.ends_with, and keys in unreadable locale files are no longer falsely reported as missing. Conversely, keys the translator cannot resolve, such as dotted array keys like ipmi.type, may now be reported as missing, so re-baseline after upgrading.
- How does it handle large codebases, many locales, and malformed translation files?
- The package is designed to audit Laravel translation files across locales, but malformed or unreadable files can affect findings. Version 0.12.7 no longer falsely reports keys in unreadable locale files as missing, which improves signal quality. For large projects, pilot on one bounded module or locale set, capture a baseline, and expand gradually.
- Does it add runtime overhead to my Laravel application?
- No, it is developer and CI tooling rather than request-path infrastructure, so its runtime footprint in production should be low. The main operational effort is Composer updates, configuration ownership, and reviewing changed findings over time. Keep it out of normal request handling and run audits in development or CI.
- What should I check before choosing it over an external TMS or JavaScript i18n workflow?
- It is a strong fit for Laravel apps using PHP-based locale files and Laravel's translator, especially modular monoliths with actively maintained translations. It is a weaker fit for JavaScript-only translation files, mobile localization, or TMS-owned workflows unless export and import integrations exist. Before adopting it, confirm support expectations, license terms, release cadence, and your pre-1.0 pinning policy.