Laravel Translation Scanner Laravel Package

Product Decisions This Supports

• Localization roadmap prioritization: the scanner inventories every translation key used in code against what exists in lang/ files, so a PM can quantify "how localized are we, really?" per locale and prioritize which languages/areas to close gaps in before a market launch.
• Release readiness / QA gating: running the scanner in CI turns "missing translation string shipped to production" into a build-time failure rather than a customer-facing bug — a cheap, concrete quality gate for any product with more than one locale.
• Build vs. buy for i18n tooling: this is the "buy/adopt" answer for key extraction and coverage reporting. It removes the case for building an in-house script that parses Blade/PHP for __(), @lang, trans() and friends — a deceptively fiddly parser problem that no product team should own.
• Content-ops and vendor scoping: unused-key detection supports cost decisions with translation vendors (you pay per word/string), and the missing-key report is a ready-made handoff artifact for translators or an agency.
• Migration and refactor safety: when keys are renamed, namespaced, or moved between JSON and PHP files, the scanner surfaces orphans and dangling references — de-risking large refactors that would otherwise silently degrade localized UX.
• Use cases it does not decide: it is not a TMS, not a runtime translation delivery layer, and not a copy-quality tool. Treat it as an audit instrument inside the engineering workflow, not as the localization platform itself.

When to Consider This Package

Adopt when:

• The product is a Laravel app with meaningful multi-locale scope (2+ locales, or a planned expansion), and translation drift is a recurring complaint.
• You want localization correctness enforced in CI rather than caught by QA or users.
• Engineering already uses Laravel's native lang/ conventions (PHP arrays and/or JSON files) and isn't planning to migrate to a hosted TMS-driven workflow in the next couple of quarters.
• You need a fast, low-cost audit of coverage and dead keys before a launch, a vendor negotiation, or a cleanup sprint.

Look elsewhere when:

• Localization is owned end-to-end by a platform like Crowdin, Lokalise, or Phrase with its own key-extraction and sync pipeline — running two scanners creates conflicting sources of truth.
• The app doesn't use Laravel's translation helpers in conventional ways (heavy runtime/dynamic key construction, keys assembled from variables, translations stored in a database or CMS) — static scanning will produce noisy, untrustworthy reports.
• You need runtime delivery, locale routing, per-user locale negotiation, or translator-facing review UI; those are out of scope here and belong to a TMS or a dedicated i18n package.
• The team cannot commit to wiring the scanner into CI. Used ad hoc, the output goes stale within a sprint and the tool quietly becomes shelfware.

Note on this release: v5.6.3 is a patch-level maintenance release with no changelog detail beyond a diff link. No breaking changes, deprecations, or new capabilities are indicated; nothing here changes the adoption calculus above. Validate the diff and confirm your pinned version's compatibility with your Laravel and PHP versions before upgrading, as with any patch.

How to Pitch It (Stakeholders)

For executives: We have a low-cost, low-risk way to stop shipping untranslated and mistranslated strings to non-English users. This package audits our Laravel codebase and tells us exactly which strings are missing per language and which are dead weight we're paying translators to maintain. That's a direct quality improvement in every non-English market and a line-item reduction in translation spend — with days, not weeks, of engineering effort and no new vendor contract.

For engineering: It's a mature, focused Laravel package that statically scans our Blade and PHP for translation keys and reconciles them against lang/. We wire one or two Artisan commands into CI and get a hard gate on missing keys plus a report of unused ones. It respects standard Laravel conventions — no runtime dependency, no changes to how translations are loaded, no lock-in. The current release is a patch with no breaking changes, so the integration cost is essentially the CI configuration plus an initial triage of whatever backlog of missing and orphaned keys it surfaces — which is exactly the debt we want visible.

Ask: approve a timeboxed spike (roughly one engineer-day) to add the scanner to CI in report-only mode, triage the first output, then decide whether to promote it to a blocking gate.