Extractor Laravel Package

Product Decisions This Supports

• Localization go/no-go, made measurable. Running the extractor over the codebase turns "how much work is translation?" from a guess into an inventory: number of unique strings, distribution per module/screen, and which surfaces (Blade views, validation messages, form labels, flash messages) are already keyed versus hardcoded. That inventory is the input to a locale-scope decision — ship 3 languages or 12, and in what order.
• Splits the build-vs-buy question into two separate decisions. Historically "localization" gets bought as one bundle. Extraction is commodity plumbing; translation memory, review workflows, glossary, and translator UX are where vendor value actually lives. Using an MIT extractor for the former frees budget and leverage for the latter, and avoids paying a TMS per-seat for string scanning.
• Lets you start i18n without committing to a vendor. Because the output is plain PHP/JSON translation files committed to the repo, extraction can land now while the TMS decision stays open for a quarter or two. The exit cost from this package is near zero; the exit cost from a TMS migration is not.
• Quantifies and sequences i18n debt. Diffs on the generated files become a per-PR signal. That supports roadmap calls like "no hardcoded user-facing strings in new code" and lets you prioritize retrofitting the highest-traffic flows (onboarding, checkout, auth) rather than sweeping the whole app.
• Sets a defensible Definition of Done. "Extraction diff is empty" is an objective, reviewable acceptance criterion, which is far more enforceable than a style-guide instruction. This is the single highest-leverage product process change the package enables.
• Informs key-naming and content-ownership decisions. The extractor's output format forces a decision the PM owns: semantic keys vs. source-text-as-key, and whether translators see PHP arrays or flat JSON. That choice shapes translator ergonomics and later migration cost — better decided before the first locale ships.
• Estimates translation spend. String counts feed vendor quotes and per-word cost models, giving finance a number instead of a range.

When to Consider This Package

Adopt if:

• The stack is Laravel/PHP on PHP 8.1+ and templates are Blade plus __(), trans(), @lang, and @choice. The release history explicitly tracks host PHP version parsing, Symfony 8 allowance, and nikic/php-parser v5, so modern syntax should parse cleanly.
• You want extraction to run as a CLI step in CI or a Composer hook, with translation files living in the repo and reviewed like code.
• You accept a pinned, self-owned OSS dependency and have someone who can own upgrades. With 128 stars and effectively zero dependents, you are close to being the first real adopter — that is fine for an internal tool, not fine for a load-bearing platform dependency with no fallback.
• Your localization need is extraction and drift-prevention, not translation management.

Look elsewhere if:

• You need a TMS, not a scanner. Review workflows, translator comments, screenshots/context, MT, glossary, and per-locale status are out of scope. Pair with Crowdin/Lokalise/Phrase rather than replacing them.
• Your frontend carries meaningful user-facing copy. The package description claims JavaScript scanning, but the release record is dominated by PHP, Twig, Symfony forms/constraints, and Blade. Treat JS/TS/Vue/React coverage as unproven and validate with a time-boxed spike; plan on i18next-scanner or equivalent for the frontend regardless.
• Your strings are built dynamically (keys assembled from variables, concatenated at runtime). Static extraction will under-report; you need runtime key logging as a complement.
• You need vendor support, SLAs, or security review of a large dependency tree. A small maintainer group and low adoption mean bus-factor risk and no commercial escalation path.
• You are on legacy PHP (<8.1) or an older Symfony/Laravel matrix. Version 2.2.0 dropped PHP 7.x–8.0; check the compatibility matrix before assuming a fit.
• It is not a PHP shop. Symfony-flavored extractors and Blade awareness have no value in a Node or Rails codebase.
• No one owns CI/tooling. The package is a building block; its value only materializes once it is wired into a pipeline and enforced.

How to Pitch It (Stakeholders)

For executives: "This is a small, MIT-licensed utility that inventories every translatable string in our PHP/Laravel codebase and keeps translation files in sync automatically. It costs nothing to license, has no vendor lock-in, and it lets us price and sequence international expansion with real string counts instead of estimates — while deferring any paid translation-platform commitment. The trade-off is honest: it is a narrowly adopted open-source tool, so we treat it as an internal, pinned dependency with an owner and a fallback, not as strategic infrastructure. Extraction is the cheap half of localization; the paid half stays a separate, later decision."

For engineering: "It is a CLI on top of nikic/php-parser v5 that walks our PHP/Blade sources, finds __(), trans(), @lang, form labels, and constraint messages, and creates or updates the matching PHP/JSON translation files while preserving existing entries. Integration is a Composer dev dependency plus one CI job; the diff is deterministic and reviewable, so it becomes a PR gate. Supports PHP 8.1–8.3 and recent Symfony. Caveats to plan for: verify JS/TS coverage before relying on it, watch for false negatives on dynamically constructed keys, and wrap it behind a single make/CI target so we can swap the tool without touching the pipeline. Ask: a 2–3 day spike to measure real string coverage and confirm parser behavior on our codebase, and one named owner for upgrades."