Laravel Translation Linter Laravel Package

Product Decisions This Supports

• Localization roadmap planning: Informs whether to invest in i18n quality tooling before or alongside launching new locales. The package catches missing, unused, and inconsistent translation keys — directly supporting go/no-go decisions on market expansion.
• Build vs. buy for translation QA: Provides a concrete "buy/adopt" baseline (free, OSS, Laravel-native) against which custom internal linting or paid localization QA (Crowdin, Lokalise checks, Phrase) can be compared.
• CI/CD gating decisions: Enables a product decision to enforce translation completeness as a merge gate, reducing user-facing fallback strings and locale-specific bugs escaping to production.
• Feature scope for i18n work: Helps size the "hygiene" workstream (key naming, orphaned strings, locale parity) separate from the "new language" workstream, so roadmap estimates reflect reality.
• Deprecation/support policy: The 3.0.1 Laravel 13 compatibility bump signals active maintenance — relevant when deciding whether this can be a long-lived dependency or must be treated as a stopgap.

When to Consider This Package

Adopt when:

• You ship a Laravel app with more than one locale, or plan to within the next 1–2 quarters.
• Translation files are hand-maintained in code (PHP arrays/JSON) rather than fully managed in a TMS.
• You want lightweight, zero-vendor-lock-in CI checks and your team is already comfortable with PHP tooling.
• You are on or moving to Laravel 13 (the 3.0.1 release explicitly adds support) and need dependency compatibility confirmed.
• You want a low-cost first step before justifying a paid localization platform.

Look elsewhere when:

• A TMS (Lokalise, Crowdin, Phrase) already owns translation lifecycle and completeness checks — this becomes redundant.
• Your translations live in a database or CMS rather than files.
• You have a single locale with no near-term i18n plans.
• You need runtime translation coverage, MT quality scoring, or translator workflow features — this is a static linter, not a platform.
• Your team has no appetite for maintaining a small OSS dependency and would rather fold checks into existing static analysis.

How to Pitch It (Stakeholders)

To executives: This is a small, free, actively maintained open-source tool that automatically catches broken or missing translations before they reach customers. It reduces the risk and cost of launching in new markets, and the latest release confirms compatibility with our Laravel 13 upgrade path — so it de-risks two roadmap items at essentially zero cost.

To engineering: A Laravel-native linter that flags missing/unused translation keys and cross-locale drift, runnable in CI. Version 3.0.1 is a maintenance release adding Laravel 13 support (dependency bump by a new contributor) — no breaking changes, no new features, low integration risk. Recommend a time-boxed spike: wire it into CI on a branch, measure false positives against our existing translation files, and decide whether to gate merges on it. Expected effort: under a day; primary risk is noise from legacy keys, which we can baseline and tighten incrementally.