Laravel Langman Laravel Package

Product Decisions This Supports

• Localization roadmap sizing. Before committing i18n to a quarter, run langman:missing and langman:show against the codebase to quantify translation debt — how many keys exist, how many locales are incomplete, and which surfaces are furthest behind. That converts "we should localize" into a scoped backlog with numbers.
• Build vs. buy vs. adopt for internal tooling. Langman sits in the "adopt" lane for a dev-time utility: it scans Blade/PHP for __(), trans(), and @lang() calls, syncs missing keys into language files, and flags unused keys. It is not a translation management system — it does not host translator workflows, review states, or runtime delivery — so it complements rather than replaces a TMS decision.
• Key convention and architecture standards. Adopting it forces a decision on translation key naming and file organization (nested PHP arrays vs. flat JSON). That decision has downstream consequences for how translators work and how keys are referenced, so treat it as an architecture input, not just a dev convenience.
• Refactor and migration hygiene. langman:find shows where a key is used and langman:remove prunes dead keys — useful when deciding whether to carry translation files into a rebuild, or to prove a legacy string set can be retired.
• Prioritizing translation completeness by surface. langman:show gives a per-locale completeness view, which supports decisions like "ship locale X to 90% before launch" or "drop locale Y from the release."
• Feature gating language support. If a market's strings are mostly missing, that is evidence against shipping that locale in the next release, independent of any marketing ask.

Caveat to carry into every one of these decisions: v1.3.5 — the newest release — adds Laravel 5.5 package auto-discovery and __() scanning. That is a useful confirmation that the scanner covers the modern helper syntax, but it also confirms the package's compatibility ceiling is the Laravel 5.5 era, with no listed dependents. Treat compatibility with the current Laravel version as an open question that must be validated before it informs roadmap commitments.

When to Consider This Package

Consider adopting when:

• You are on Laravel 5.5 or a nearby 5.x version, where v1.3.5 installs via package auto-discovery — a single composer require with no manual service provider registration and no config file to publish. If you are on a materially newer Laravel, verify before assuming, or be willing to fork and maintain it internally.
• Translation strings live in the repo as file-based lang/ resources, not in a database or a third-party service.
• The team is small, locales are few (roughly 2–6), and the current pain is mechanical: keys drift, translators get incomplete files, and unused keys accumulate.
• You need a fast, zero-cost way to audit existing translation coverage before making an i18n investment decision.
• Your code prefers the __() helper: v1.3.5 explicitly adds scan support for it, so the completeness numbers now reflect the dominant modern calling convention rather than under-reporting it.
• You want a dev-only dependency with no runtime footprint — it does not touch request handling, so blast radius is limited to developer workflow.

Look elsewhere when:

• You are on modern Laravel and the package does not install or run cleanly; the maintenance cost of a fork may exceed the value. Prefer an actively maintained alternative or a thin in-house artisan command.
• The fact that the latest feature is 5.5 auto-discovery is itself a signal: this package is feature-stable by abandonment, not by design. Assume no further compatibility work is coming.
• You need runtime or database-backed translations, per-tenant overrides, or hot-swappable strings — that is spatie/laravel-translation-loader territory, not this.
• You need translators to work in a UI with review, approval, and machine-translation assistance — that is a TMS purchase (Crowdin, Lokalise, Phrase) and a different budget line.
• Your code uses heavily dynamic translation keys (__($var), computed key segments). Static scanning will miss or misreport these, and the completeness numbers become untrustworthy — the new __() support is literal-call scanning, not resolution.
• You have many locales or high string churn; manual sync plus a CLI audit will not keep pace.
• Your translation files are large JSON blobs rather than nested arrays — confirm behavior before assuming parity.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed developer utility that reduces the engineering hours spent maintaining translation files and gives us a defensible number for how complete each language actually is. The latest release tightens the install story on Laravel 5.5 — it registers itself automatically, so evaluation is a one-line dependency add in a branch — and extends scanning to the __() helper, which means the coverage numbers we would report are based on how our code is actually written today. It is dev-time only: it does not ship to production, adds no runtime risk, and can be evaluated at effectively zero cost. The honest caveat is maintenance: the newest release only reaches Laravel 5.5, so the recommendation is a short, time-boxed spike against our Laravel version, with a fork-and-own or thin in-house command as the fallback. Treat it as a cheap measurement and hygiene tool, not a strategic platform decision.

To engineering: Run langman:show and langman:missing to get a coverage grid and a gap list, langman:sync to scaffold missing keys from actual usage in views and PHP, langman:find to locate usages before a refactor, and langman:remove to prune dead keys. v1.3.5 adds __() scanning and Laravel 5.5 auto-discovery, so on a 5.5-era app rollout is composer require in a branch with no provider registration; on a newer app, budget a short spike to confirm it boots and scans correctly before you rely on the output. If the scan produces false negatives on dynamic keys, that tells us our key conventions need tightening — useful signal either way.

To product/design: It will not give you a translator-facing editor or a workflow for review. What it gives you is a fast, repeatable answer to "how translated are we, really?" — which is the input we need before promising a locale in a launch plan.