Extractor Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. An extraction tool is the prerequisite for any i18n commitment: you cannot estimate translation cost, vendor selection, or launch timelines without a reliable inventory of translatable strings. Deciding to adopt (or benchmark) a tool like this is effectively the decision to measure localization scope rather than guess at it.
• Build vs. buy for the translation pipeline. The package answers one narrow question — "can we pull keys out of source automatically?" — which lets you separate that commodity step from the parts worth paying for (TMS, MT, review workflows). If extraction is cheap and scriptable, budget goes to translation quality and reviewer tooling instead.
• Framework standardization and developer experience. Choosing a native PHP/Laravel extractor instead of a polyglot tool is a stack-coherence decision. It signals that PHP source is the canonical string source, which shapes onboarding docs, CI templates, and linting rules.
• Hardcoded-string remediation as a trackable workstream. Extraction output becomes a backlog artifact: counts of untranslated strings per module, per release, per team. That converts a vague "we should localize" initiative into sprint-sized tickets with acceptance criteria.
• CI gating policy. Whether to fail a build on missing keys or merely report them is a product-quality decision (broken UI strings vs. slower merges). The tool's output format and exit behavior constrain which policy is feasible.
• Roadmap risk register. The package's maturity signals — 0 stars, 0 dependents, score 0 — make "unmaintained dependency" a tracked risk with an owner, a fork plan, and a review date, rather than an unexamined assumption.

When to Consider This Package

Consider it when:

• The product is a PHP/Laravel codebase where translation calls are conventional (__(), trans(), @lang) and statically greppable.
• You need inventory, not runtime behavior — this is a developer/CI-time utility, so blast radius is small and reversible. A spike costs hours, not a sprint.
• You want a throwaway or forkable extraction step for a one-off audit: sizing a localization effort, preparing a TMS migration, or establishing a baseline before committing to a vendor.
• Licensing is clean for your policy (MIT is permissive; vendoring and patching are legally straightforward).
• You can own the code — assign a maintainer, pin a version, and accept that upstream fixes may never arrive.

Look elsewhere when:

• You need a supported dependency with an SLA, security response, or a community to escalate to. Zero stars and zero dependents means zero social proof; treat it as unattributed source code you are adopting, not a product.
• Your strings live outside PHP — JS/TS front ends, Blade and Vue templates, mobile clients, or a monorepo — or you need pluralization, context, and ICU MessageFormat awareness. Mature extraction lives inside TMS CLIs (Crowdin, Lokalise, Phrase) and gettext/xgettext toolchains, which also handle round-tripping.
• You already pay for a TMS whose CLI does extraction; a second, unmaintained extractor creates two sources of truth for keys.
• Compliance or supply-chain review (SBOM, dependency scanning) flags single-maintainer packages with no release history — the political cost of the exception usually exceeds the tool's value.
• The team's real bottleneck is translation throughput or review, not string discovery. Extraction is the cheapest part of localization; solving it well does not move the metric that matters.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed developer utility that scans PHP source code and lists every string we would need to translate. It is not shipped to customers and adds no runtime risk, so the downside is bounded — worst case we spend a few engineering days and discard it. Its strategic value is measurement: it replaces estimates about localization cost with an actual count, which is what we need before committing budget to a translation vendor or a launch date in new markets. Caveat worth stating plainly: the project has effectively no community (zero stars, zero dependents) and no support. I recommend a timeboxed evaluation, adoption only behind a pinned version with a named internal owner, and no roadmap dependency on upstream maintenance.

For engineering: It's a dev-time, CI-friendly extractor for Laravel translation calls — low integration cost, no production footprint, easy to remove. The trade-off is maintenance: we'd be adopting unowned code, so the deal is a timeboxed spike, a fork-or-vendor decision if it proves useful, and a test suite around its output so an upstream disappearance is a non-event. If the spike shows gaps in Blade/JS coverage or plural handling, we stop and evaluate TMS-native extractors instead — that is a valid, cheap outcome.