Laravel Translatable String Exporter Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. This package makes it cheap to answer "how fast can we ship locale N?" By automating extraction of translatable strings from Blade templates, PHP, and JavaScript into JSON language files, it turns internationalization from a multi-sprint engineering project into a recurring, low-effort workflow — which directly informs whether i18n belongs in the next quarter or the one after.
• Build vs. buy on translation tooling. It is a credible first investment before committing budget to a Translation Management System (Crowdin, Lokalise, Phrase, Weblate). The JSON output it generates is the de facto interchange format most TMS platforms ingest, so adopting it does not lock the team out of a later buy decision — it de-risks and often accelerates it.
• Storage-format decision. Choosing JSON-based language files (rather than PHP array files) is a durable architectural call that affects TMS compatibility, translator ergonomics, and frontend consumption. This package effectively advocates for and normalizes that choice.
• Feature-shipping velocity. New copy can be written in the standard Laravel helpers (__(), @lang(), trans()) and extracted automatically, so product teams are not blocked on manually curating key files or on translation ops before merging UI work.
• Translation drift as a quality metric. Because extraction can run in CI, it enables a "translation coverage / drift" signal (untranslated keys, orphaned keys) that product can track as a release-readiness gate for localized markets.
• Use cases it unblocks: MVP international expansion, adding a second or third locale without dedicated localization engineers, preparing strings for outsourced translation, catching hardcoded strings during code review, and keeping parity between source and target locales over time.

When to Consider This Package

Adopt when:

• You are on Laravel (or a Laravel-adjacent stack) and strings already use the framework's standard translation helpers.
• Language files are maintained by hand and keys are drifting — missing keys, stale keys, or strings hardcoded in templates that never made it to a lang file.
• You want a zero-cost, MIT-licensed, Composer-installable tool with no runtime dependency and a single artisan command to learn.
• You need a repeatable, CI-friendly extraction step whose output (JSON) can be handed to translators or pushed into a TMS.
• The team is small-to-mid and does not have a dedicated localization engineer or pipeline.
• You are still evaluating whether localization is worth deeper investment and want evidence (volume of strings, churn) before spending.

Look elsewhere when:

• You already run a TMS with native repository integrations (Crowdin, Lokalise, Phrase, Weblate) that pull source strings directly — this would duplicate that function.
• Strings live predominantly outside Laravel (a heavy SPA, React Native, mobile clients, microservices). You would need per-stack scanners (e.g., i18next-scanner) rather than a Laravel-specific one.
• You need capabilities beyond extraction: translation memory, machine translation, vendor/translator workflow, review states, or in-context preview. This package extracts; it does not manage translation.
• You rely on complex ICU message formats, gender/plural rules beyond what the framework handles, or namespace/key conventions the extractor does not recognize.
• You are in a multi-app monorepo needing a centralized string catalog, or your strings are generated dynamically at runtime in ways static extraction cannot see.
• Your organization requires an actively maintained vendor with SLAs; a 330-star community package with an MIT license is a reasonable dependency, but it is not a supported commercial product.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed, open-source utility that removes most of the manual labor from translating a Laravel product. It scans the codebase, finds every user-facing string, and produces clean JSON files ready for translators or a translation vendor. The business case is time-to-market for new markets: instead of weeks of engineering busywork every time we add a locale, we get a repeatable command and a CI check. Cost is effectively zero, the license carries no commercial obligation, and it commits us to nothing — the output format is standard, so if we later buy a Translation Management System, this work feeds directly into it rather than being thrown away.

For engineering: Install via Composer; one artisan command walks Blade, PHP, and JS and writes/updates the language JSON. No runtime dependency, no changes to how __() / @lang() behave, and it is straightforward to wire into CI to flag missing or orphaned keys. It is deliberately narrow — extraction only — so it will not fight an existing TMS or a different i18n stack, and it can be removed without touching application code.

Recommendation: Adopt as the default localization workflow for Laravel services in the near term. Reassess if string volume or translator workflow complexity outgrows static extraction, at which point this becomes the source-of-truth generator feeding a TMS rather than a tool to replace.