Product Decisions This Supports
- Localization QA as a release gate. The bundle's core value proposition — scanning templates for translation calls and cross-checking them against message catalogs to surface missing, unused, or orphaned keys — maps to a recurring PM decision: do we ship a locale as "done," or only when coverage is verified? This package is evidence that the problem is real and that teams want it automated rather than caught in QA.
- Roadmap sizing for i18n work. A missing-key report is the cheapest possible input to estimating "how much work is left before we can launch locale X." If you're deciding between launching three locales shallowly or one locale properly, key-coverage data is the quantifier.
- Build vs. buy for tooling. With 14 stars, 0 dependents, and a last release in January 2015, this is a reference implementation, not a dependency. The decision it informs is: buy a managed TMS (Crowdin, Lokalise, Phrase), adopt a maintained open-source checker, or write ~200 lines of artisan-command glue yourself.
- Vendor/stack risk review. It's a Symfony bundle, and the framing "Laravel/PHP package" is a trap — Laravel does not consume Symfony bundles. Any decision to use it implies porting the scanning logic into a Laravel service provider or command. That port cost is the real line item.
- Deprecation / debt triage. If an existing project depends on this, the PM decision is a migration plan, not an adoption plan.
When to Consider This Package
Consider it only as reading material — a compact, MIT-licensed example of how to structure translation-coverage checks — if all of the following hold:
- You're on Symfony 2.x and inheriting a codebase that already uses it (the only genuinely low-friction case).
- You want to understand the shape of the problem before writing your own checker, and a 2015 codebase is acceptable as inspiration.
- Your translation catalogs are file-based (XLIFF/YAML/PHP arrays) and your templates call translations through a single, greppable convention.
Look elsewhere — decisively — when:
- You're on Laravel. Bundles are not service providers; assume full porting effort.
- You need maintenance guarantees. No release in ~10 years, 0 dependents, and an ecosystem (PHP 5/7, Symfony 2/3) that has moved several major versions past it. No security response, no PHP 8 compatibility, no CI.
- Your translations live in a TMS. Managed platforms already do missing-key detection as a first-class feature; you'd be duplicating it badly.
- You need runtime or CI-grade reliability. Prefer a maintained linter (e.g., a Laravel translation-key linter, PHPStan rules, or your CI's existing static analysis) over an unmaintained bundle.
- You need pluralization, ICU MessageFormat, namespaced/vendor keys, or dynamic key construction. Grep-based checkers handle these poorly; this one almost certainly does not address them.
How to Pitch It (Stakeholders)
To executives: This is an old, small, MIT-licensed Symfony bundle that automates catching missing translation strings before release. It is not something we should adopt — it hasn't been updated since 2015 and nearly no one uses it. Its value to us is as a cheap reference for a capability we should have, not a component we should install. Recommendation: spend a half-day spike building the equivalent check into our CI (or enable the feature in our translation platform), and close the question.
To engineering: Treat mdm/translator-checker-bundle as prior art. It demonstrates the pattern — parse templates for translation calls, diff against catalog files, report missing and unused keys — in a codebase small enough to read in an hour. Do not add it as a dependency: it's a Symfony bundle, incompatible with our service-provider model, pinned to an EOL PHP/Symfony generation, and unmaintained. The deliverable we actually want is a php artisan translations:audit command (or an equivalent CI job) that fails the build on missing keys for any locale we've declared "launched," plus a report of unused keys for cleanup. Estimate that against the cost of a TMS tier upgrade, and pick one.
One-line framing: Useful idea, dead code — copy the idea, not the package.