Laravel Missing Translations Laravel Package

Technical Evaluation

Architecture fit. webduonederland/laravel-missing-translations is a developer-tooling package, not a runtime dependency: it registers a service provider and exposes an Artisan command that scans Blade templates and PHP source for translation keys (__(), @lang, trans()) and reports keys that resolve to nothing in the configured lang paths. That places it squarely in the static-analysis / CI-linting layer of a Laravel codebase, alongside PHPStan, Pint, and Pest. It does not sit on the request path, does not touch the database, and does not alter translation resolution at runtime — which is the single most important fact for a TPM: the blast radius of adopting it, or of it breaking, is bounded to the developer workflow.

Integration feasibility. Very low effort. Standard composer require --dev, Laravel package auto-discovery, one published config file, one Artisan invocation. Release 1.3.0 explicitly adds Laravel 13 support, which is the material change here — it removes the version ceiling that would otherwise block adoption on teams already planning a Laravel 13 upgrade. The accompanying "bugfix in config publish" is a quality-of-life fix: it means vendor:publish --tag=config produces a working config rather than a malformed or mis-tagged file. Both changes are additive/compatible; neither is a breaking change.

Technical risk. Low-to-moderate, and concentrated in two areas rather than in the code itself:

1. Maintainer risk. This is a small, single-maintainer package (@FinnPaes) with a short release history (the changelog link compares 1.1.0…1.2.0 for a 1.3.0 release). Laravel-13 support arriving is a good signal of active maintenance, but the bus factor is 1. Mitigation is cheap: pin the version, keep it require-dev, and accept that a fork is a few hundred lines if the package is abandoned.
2. Signal quality. Static key extraction is inherently heuristic. Keys built dynamically (__("errors.{$code}"), keys from config, keys from a DB) will be reported as missing or silently skipped. A noisy tool gets disabled by the team within two sprints; the assessment should treat "false-positive rate on our codebase" as the primary adoption gate, not installation.

Key questions.

• What is the false-positive rate against a real service in our portfolio? We need a dry run before any commitment.
• Does it handle all the lang storage shapes we actually use — PHP array files, JSON files (lang/en.json), nested vendor namespaces (vendor::file.key), and pluralization (trans_choice)?
• Does the command exit non-zero on findings, and can the threshold be configured? This determines whether it can be a blocking CI gate or must stay advisory.
• What is the scan time on our largest repository, and can paths be scoped to avoid vendor/ and node_modules/?
• Which Laravel/PHP versions does it actually support below 13? We need a floor for services still on 10/11.
• Is there a baseline/allowlist mechanism for pre-existing debt?

Integration Approach

Stack fit. Assumes a conventional Laravel app or package with lang/ at the project root (Laravel 9+ layout). It is a require-dev dependency only — it should never appear in a production composer.json require block, and there is no reason to ship it to runtime images.

Migration path. Treat as greenfield rather than a migration. There is no incumbent tool to displace, so the path is: install into a single representative service → run report-only → triage output by hand → decide. If a team currently maintains a bespoke grep/PHP script for the same job, run both in parallel for one release cycle and compare output before retiring the script; the custom script may encode project-specific conventions (e.g. a key prefix scheme) that the package will not know about.

Compatibility. 1.3.0 is backward compatible with earlier 1.x. The config-publish bugfix means teams that previously published a broken config should republish and diff — but since the package is new to us, this is a non-issue on first install. The Laravel 13 support is the reason to prefer 1.3.0 over 1.1.0/1.2.0 for any service on or approaching 13, and there is no penalty for using it on 10/11/12 if the constraint permits. Verify the constraint in composer.json at install time rather than trusting the release title: the changelog's compare link (1.1.0...1.2.0) does not match the announced 1.3.0, so confirm the tag actually exists and what it requires.

Sequencing.

1. Spike (½ day): install in one mid-size service, run the command, capture output and scan duration.
2. Triage: classify findings into genuine gaps, dynamic-key false positives, and vendor/third-party noise. This classification is the actual deliverable of the spike.
3. Pilot as advisory: add to CI as a non-blocking job with output posted to the PR. One sprint of observation.
4. Promote to blocking only if the genuine-gap category is actionable and the false-positive category can be suppressed via path scoping or an allowlist. Otherwise keep advisory permanently — a permanently red non-blocking check is worse than no check.
5. Roll to additional services only after the pilot's config is proven; standardise the published config across repos so results are comparable.

Operational Impact

Maintenance. Near zero ongoing cost. No runtime footprint, no schema, no data migration, no cron. The only recurring work is a composer update on the normal dev-dependency cadence, plus a re-run of the triage step whenever the package's detection logic changes materially. Budget roughly a day of engineering for the initial spike-and-triage and a few hours per quarter thereafter.

Support. The support story is "self-serve plus fork." With a single maintainer, we should not expect SLAs, rapid issue turnaround, or guaranteed forward-compatibility with future Laravel majors — 1.3.0's Laravel 13 support was delivered, which is reassuring but is one data point. Pin to ^1.3 in composer.json so an unexpected 2.0 cannot break CI silently. Because the package is dev-only and small, the fallback (vendor the code or fork it) is realistic; note this explicitly in the adoption record so the decision is not re-litigated later.

Scaling. Scales linearly with repository size, not with traffic or user count — the "scaling" concern here is CI wall-clock time on large or monorepo codebases. Scope the scan to application source directories and exclude generated code, build artefacts, and third-party paths. For monorepos with multiple Laravel apps, expect to run per-app with distinct configs; a single repo-wide invocation will blend translation namespaces and produce misleading results. On very large repos, run it on a schedule or on changed-paths only rather than on every push.

Failure modes.

• CI breakage from a version bump: an unpinned constraint pulling a version that changes exit codes or output format. Mitigated by pinning.
• False-positive fatigue: the command flags dynamic keys, keys in vendor packages, or keys resolved at runtime; developers either add blanket suppressions or disable the check. This is the most likely failure and the reason for the advisory-first sequencing.
• False negatives creating false confidence: teams may read a green run as "translations are complete" when the tool only sees statically extractable keys. Document the tool's scope in onboarding material so it is understood as a lint, not a guarantee.
• Config publish overwrite: running vendor:publish with force on an already-configured repo would clobber tuned settings. Use --tag without --force and keep the config in version control.
• Silent abandonment: package stops receiving Laravel majors; the constraint blocks the framework upgrade at the worst possible moment. Re-check maintenance health at each Laravel major, not each package release.

Ramp-up. Effectively nil for developers — one command, output is self-explanatory. The real ramp-up is organisational: agreeing what the check enforces, who triages the initial backlog of missing keys, and whether translation completeness is a release gate. That governance conversation is a day of TPM work and is the difference between a useful lint and a disabled CI job. Recommend: pilot on one service, publish the triage results as the go/no-go artefact, and only then write the check into the team's definition of done.