- What does fidum/laravel-translation-linter do?
- It is a developer-tooling package that lints your Laravel language files for missing, unused, duplicate, and inconsistent translation keys across locales, plus common syntax issues. It runs as an Artisan command so you can keep lang files clean, complete, and in sync. It does not touch request handling or runtime behaviour, so it is purely a quality gate for translations.
- How do I install fidum/laravel-translation-linter in a Laravel application?
- Add it with Composer as a dev dependency, typically using a caret constraint such as ^3.0. There are no migrations, published assets, or service provider behaviour that alters your application, so installation is effectively a single Composer command. After that you can invoke the package's Artisan command against your lang directory.
- Is it a runtime dependency or a require-dev tool?
- It is a dev-only tool and belongs in require-dev, not require. Because it never participates in request handling, it has no bearing on application architecture, container bindings, or runtime performance. That also means a breakage degrades developer workflow rather than production availability.
- Which Laravel versions does fidum/laravel-translation-linter support?
- The 3.0.1 release widens the dependency constraint to include Laravel 13, and there are no reported API or behavioural changes in that patch. If your estate still runs Laravel 10, 11, or 12 with older PHP versions, verify the composer.json constraints before rolling out, since the Laravel 13 bump may also affect the minimum PHP requirement. Confirm that ^3.0 does not drop support for your oldest supported application.
- Can I run fidum/laravel-translation-linter in a CI pipeline?
- Yes, wiring it into CI is one of the main intended uses, alongside local pre-commit runs. The practical decisions are where it executes and what failure policy you attach to its exit code. A common approach is to start the CI job in non-blocking or warn-only mode for a sprint before making it a hard gate.
- What translation problems does it detect?
- It flags missing keys, unused keys, duplicate keys, and inconsistent keys across locales, along with common syntax issues in the language files. That combination helps keep language files complete and in sync before a release. It is aimed at file-based lang directories rather than translations fetched from a database or external service.
- Does it work with JSON translation files or lang paths registered by packages?
- The package assumes a traditional file-based lang/ directory, and its coverage of non-standard loading is not clearly documented. JSON translations, lang paths registered by third-party packages, and Spatie-style translation storage should be tested in a throwaway branch before you depend on the results. Treat any gaps as a scoping question rather than a blocker for standard setups.
- How should I roll it out without blocking my team?
- Because this is a greenfield adoption, install it in one representative repository first and run the command manually to see the output volume. Baseline the current violation count so the first enforced run does not fail delivery, then add the CI job in non-blocking mode and publish a short internal note. Only retire any overlapping custom script or static-analysis rule after the new command has run in warn-only mode for a sprint.
- Should I parse the command's output in scripts, or rely on exit codes?
- Relying on exit codes is the safer choice. Output parsing is the main coupling risk across future major versions, since a major could change the output format or CLI flags in ways that break your CI parsing. If you do need structured results, wrap the parsing behind a small adapter you can update in one place.
- Is fidum/laravel-translation-linter actively maintained, and what is the risk?
- The 3.0.1 release is a dependency-support patch that came from a new contributor, which is a positive signal but not a long track record. The residual risks are the usual ones for a small package: bus factor, low release cadence, and possible output or flag changes in a future major. Because it is dev-only, any breakage affects developer workflow rather than production, and the package's scope overlaps with what custom scripts can do if you ever need an alternative.