Translation Checker Bundle Laravel Package

Product Decisions This Supports

• Localization roadmap scoping. The tool surfaces missing, unused, and inconsistent translation keys across a Symfony project's locale files. That gives you a defensible estimate of remaining i18n debt before committing a market launch date, rather than discovering gaps during QA.
• Build vs. buy on translation QA. The alternative to adopting this is writing bespoke key-auditing scripts or buying a TMS with linting built in. With zero licensing cost (MIT) and no runtime dependency, the build-vs-buy calculus collapses toward "buy" — the adoption cost is an afternoon of CI wiring, not a sprint of script maintenance.
• Release gating / definition of done. Unused and missing keys are objective, automatable signals. This makes it feasible to add a translation-completeness check as a merge gate without arguing about subjective copy quality, which is the usual reason localization work never gets enforced.
• Prioritizing new locale launches. Running the checker across candidate locales tells you whether the marginal cost of locale N is a handful of keys or a full translation pass. That is direct input to whether a locale goes in the roadmap now, next quarter, or never.
• Identifying dead weight in the translation pipeline. Unused-key detection is the only reliable way to retire translation spend on strings that no longer render. For teams paying per-word to vendors, this is a recurring cost-reduction lever, not a one-time cleanup.
• Sequencing refactors. Before a template or domain restructuring, the checker establishes a baseline so you can prove the refactor didn't silently orphan keys — useful when translation files are owned by a different team than the code.
• Framing the platform-upgrade decision. As of v1.10.0 the bundle requires PHP 8.2+ and Symfony 6.4+, and supports Symfony 8. That makes the tool itself a concrete forcing function: if a service is still on Symfony 5.x/6.0–6.3, adopting the current release means upgrading the runtime first. Useful as a data point in the "when do we do the framework upgrade" conversation, since it turns an abstract modernization argument into one with an attached capability.

When to Consider This Package

Adopt when all of the following hold:

• The application is Symfony, not Laravel. This is a Symfony bundle and will not drop into a Laravel codebase — the "Laravel/PHP package" framing in the request is a category error worth correcting before it reaches a stakeholder. For Laravel, look at laravel-translation-manager-style tooling or a language-server/static-analysis approach instead.
• You are on PHP 8.2+ and Symfony 6.4+. As of v1.10.0 the bundle hard-drops Symfony below 6.4 and PHP below 8.2 (PR #45). Budget the runtime upgrade before the tooling upgrade if you are behind — pin v1.9.1 in the interim if the older constraint is a blocker, but understand you are then on an unmaintained branch.
• Translations live in file-based catalogs (YAML/XLIFF/PHP arrays) under version control, and engineering owns them. If a TMS or a database-backed translation store is the source of truth, this tool sees a stale mirror at best.
• You have a CI pipeline you control and can add a step to. The value is realized on every commit; running it ad hoc is a one-time audit with a short shelf life.
• You have more than one locale, or are actively adding one. Single-locale projects gain almost nothing.
• You can tolerate a small, single-maintainer-led dependency. 36 stars and zero dependents means thin community validation and no downstream pressure testing. Because it is a dev-only CLI with no runtime footprint, the blast radius of abandonment is contained — you can fork or replace it — but do not treat it as infrastructure.

Look elsewhere when:

• You need runtime translation management (editing strings in an admin UI, hot-reloading copy). This is a build-time linter, not a translation platform.
• You need translation quality signals — tone, length constraints, placeholder/plural correctness across languages. This checks presence and usage, not correctness; you need vendor QA or an MT-evaluation layer for that.
• You want managed workflow — assignment, review states, vendor handoff. That is a TMS decision, and adopting this does not advance it.
• Your team is not PHP/Symfony-fluent. The tool is small but the failure mode is silent CI noise that nobody triages, which is worse than no check.
• You are on PHP < 8.2 or Symfony < 6.4. This is no longer a "maybe verify" risk; it is an explicit, documented incompatibility as of v1.10.0. Upgrading the runtime is the prerequisite, not a footnote.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed developer tool that automates translation completeness checks in our Symfony CI pipeline. It converts localization from a manual, end-of-cycle scramble into a per-commit signal — so launch dates for new markets are based on measured translation gaps rather than estimates, and we stop paying vendors to translate strings that no longer appear anywhere in the product. Total cost is a few hours of engineering setup and no licensing or infrastructure spend. The v1.10.0 release adds Symfony 8 support, which means the tool tracks the current framework line rather than lagging it, and it now requires PHP 8.2+/Symfony 6.4+ — so any service we apply it to must already be on a supported runtime. The remaining caveat is that it is a small open-source project with one lead maintainer, which we mitigate by treating it as a replaceable dev-time utility rather than a platform dependency.

For engineering: Add it as a dev dependency; note that v1.10.0 dropped Symfony <6.4 and PHP <8.2, so confirm your composer.json platform constraints before pulling it in — on older stacks, pin to v1.9.1 and plan the upgrade rather than discovering the conflict mid-sprint. Wire its check commands into CI as a non-blocking report first, then promote to a gate once the baseline is clean. It has no runtime footprint: it reads translation catalogs and reports missing and unused keys. Expect to spend the first pass triaging existing noise — an inherited codebase will have both false positives and genuine orphans, and the gate is only credible after that baseline is agreed.

Recommendation: Worth a low-cost spike on the Symfony services where we own the catalogs and are already on PHP 8.2+/Symfony 6.4+. Do not position it as a localization strategy; position it as the cheapest available enforcement mechanism for a strategy we have already decided on.