Laravel Missing Translations Laravel Package

Product Decisions This Supports

• Localisation QA as a build-time gate, not a launch-week scramble. The package's core job is surfacing translation keys that exist in code but are missing from one or more locale files. That converts "we found 40 missing strings in the German build" from a manual QA finding into an automated check you can run in CI. For any roadmap item that adds or expands a locale, this is the tool that tells you how much translation debt the feature actually created.
• Roadmap scoping for internationalisation. Before committing to "add 5 new markets this quarter," run this against the codebase to get a defensible count of untranslated strings per locale. That number is the input to the translation-vendor budget and the realistic ship date — far better than a PM guessing "a few hundred strings."
• Build vs. buy: this does not replace a TMS (Crowdin, Lokalise, Phrase). It replaces the discovery step that feeds one. Frame the decision as: adopt this as free, in-repo tooling to keep the source-of-truth clean, and only buy a TMS when you have human translators or >2 locales in active rotation. The two are complementary, not competitive.
• Feature-level use cases: pre-release audits of new screens, regression checks after refactors that move keys around, onboarding visibility for engineers who don't own the locale files, and a cheap sanity check when a new locale is added to config/app.php.
• Release 1.3.0 specifically: the Laravel 13 support line matters because it removes an upgrade blocker. If your platform roadmap includes moving to Laravel 13, this package is no longer a "we'll deal with it later" line item on the migration checklist — it's cleared. The config-publish bugfix is a developer-experience fix, not a product decision driver, but it does mean new adopters get a working vendor:publish path on first install rather than a support ticket.

When to Consider This Package

Adopt when:

• You are on Laravel 13 (or 11/12) and ship more than one locale, or plan to within the next two quarters.
• Your translations live in standard Laravel lang/ PHP or JSON files and you are not yet on a TMS.
• You want a low-ceremony, zero-runtime-footprint dev dependency — this is a dev-only tool, so it shouldn't appear in production dependency audits or affect request performance.
• You have engineers, not translators, adding keys, and want a mechanical way to catch the ones they forget.

Look elsewhere or deprioritise when:

• You already have a mature TMS pipeline with a CLI that does key extraction and missing-key detection (Crowdin CLI, Lokalise CLI). Duplicating that creates two sources of truth for "what's missing."
• Your translations are managed at runtime through a database or admin UI (e.g. spatie/laravel-translation-loader). A file-scanning tool will fight that model rather than help it.
• You need translation coverage reporting across namespaces, per-locale dashboards, or stakeholder-facing analytics — that's a TMS or a custom report, not this.
• You need automatic machine translation of missing keys. This class of tool finds gaps; it doesn't fill them.
• You're a single-locale product with no near-term i18n plans. Zero value today.

Diligence note before adoption: the 1.3.0 release notes reference a changelog comparison of 1.1.0...1.2.0, so the tag and the linked diff don't line up. Worth confirming with the maintainer or pinning to a specific tag and verifying the Laravel 13 constraint in composer.json yourself rather than trusting the release title. Small package, single maintainer — factor maintenance risk into the decision, and be prepared to vendor it if it goes quiet.

How to Pitch It (Stakeholders)

For executives: This is free, developer-only tooling that catches untranslated text before it reaches customers in new markets. The cost is effectively one afternoon of engineering setup; the return is fewer localisation defects at launch and a real number — not an estimate — for what a new market launch will cost in translation. It also clears a dependency from the Laravel 13 upgrade path, so it de-risks a platform migration we already have on the roadmap.

For engineering: Add it as a require-dev dependency, wire it into CI as a non-blocking report first and a blocking check once the baseline is clean, and publish the config to tune which paths and locales it scans. It has no runtime presence, no database, and no service provider overhead in production. The 1.3.0 release adds Laravel 13 support and fixes config publishing — verify the tag before pinning, as the release notes' changelog link is inconsistent.