Laravel Find Missing Translations Laravel Package

Product Decisions This Supports

• Localization coverage as a launch gate: this package scans Blade/PHP source for translation keys used but missing from lang/ files, giving a PM an objective, automatable check for whether a locale is actually "done" before a market launch or a localized campaign.
• i18n roadmap sequencing: a repeatable report of missing keys per locale tells you which languages are cheap to finish versus effectively unstarted — useful evidence when arguing for adding or deferring a locale in the next quarter.
• Build vs. buy for QA tooling: it's a small, free, single-purpose dev dependency; the alternative is a commercial TMS (Phrase, Lokalise, Crowdin) with built-in coverage checks. Use this when you want the coverage signal without a vendor contract; the 1.8.1 fix (recognizing a locale declared in either short or verbose form and labeling the offending file) directly improves the trustworthiness of that signal in mixed-format repos.
• Definition of done for feature work: "no new missing-translation entries" is a low-friction acceptance criterion engineering can wire into CI, which reduces the PM-level risk of shipping English strings into non-English flows.
• Release/regression confidence: as a patch release, 1.8.1 is a maintenance signal — the maintainer still ships fixes — but it is not a product capability change and should not be sold internally as new functionality.

When to Consider This Package

• Adopt when: the product is Laravel-based, translations live in standard lang/ files, and you have (or plan) more than one locale — especially if you lack a TMS with coverage reporting.
• Adopt when: you want a CI-friendly, zero-cost guardrail rather than a process document that says "please remember to add translations."
• Adopt when: your team mixes locale directory conventions (en vs en_US) or uses verbose locale declarations; 1.8.1 specifically hardens detection for that case and reports the file in the verbose output, which matters for triage.
• Look elsewhere when: you need translation memory, string ordering, translator workflows, MT, or per-key review states — that is a TMS, not a linter.
• Look elsewhere when: translations are stored in a database, a headless CMS, or fetched at runtime from a service; static scanning won't see them.
• Look elsewhere when: you need guaranteed vendor SLA/support — this is a single-maintainer open-source utility, and the 1.8.1 patch (a locale-format edge case) is a reminder that behavior at the margins evolves; budget for occasional version pinning.

How to Pitch It (Stakeholders)

For executives: this is a free developer tool that automatically finds text in the product that has no translation yet. It converts "are we actually localized?" from a subjective judgment into a reportable, automatable number, which de-risks international launches and tells us where the next localization dollar is best spent. Cost is effectively zero; the only commitment is a small amount of engineering setup and CI time. The 1.8.1 release is a routine bug fix improving accuracy for projects that name locales in different formats — no cost, no migration, no decision required.

For engineering: a dev-only dependency that statically scans for translation keys and reports ones missing from the locale files, with a CI-usable exit signal. 1.8.1 is a patch: it treats a locale as declared whether written in short or verbose form and names the file in the verbose report line. No breaking changes, no API surface change, safe to take on a patch bump. Recommend pinning and wiring into a non-blocking CI job first, then promoting to blocking once the baseline backlog is burned down — otherwise the first run will fail every build.