Localizator Laravel Package

Product Decisions This Supports

• Internationalization (i18n) roadmap sequencing — Localizator tells you how much hardcoded copy is sitting in your Laravel codebase and how much work remains before a market launch. That data turns "localize into 5 languages" from a vague epic into a measurable backlog item.
• Build vs. buy for translation string extraction — Rather than assigning engineering to hand-audit Blade templates and PHP files for __(), @lang, and untranslated literals, this package gives you an instant artisan-based inventory. It is the "buy" option priced at a composer require.
• Localization readiness assessment before a launch — Run it per module or per repo to identify where copy is hardcoded vs. already using translation keys. This informs whether a market launch is a small sprint or a multi-quarter program.
• Feature scoping: does this feature need translation keys from day one? — Use the extraction output as a definition-of-done check for new features in multi-locale products, and as a lint-style gate for engineering.
• Vendor/TMS handoff planning — The extracted files become the input artifact for translation agencies or a TMS (Lokalise, Phrase, Crowdin). This affects procurement decisions and translation budget estimates.
• Technical debt and code-quality prioritization — A count of untranslated strings per file/module is an objective input for prioritization, not a subjective "the code is messy" complaint.
• Use cases: multi-market SaaS, Laravel admin panels and customer portals, regionalized e-commerce storefronts, agency client work where localization is a recurring deliverable, and post-acquisition code audits.

When to Consider This Package

Consider it when:

• The product is a Laravel application (this is the hard requirement — it is not framework-agnostic).
• You already use, or intend to use, Laravel's native lang/ file convention — the package's value is the direct output into those files.
• You need a repeatable, scriptable inventory of untranslated strings rather than a one-off manual audit; the artisan command slots into CI or a release checklist.
• Localization is a recurring workflow (new features ship continuously), not a one-time migration.
• You want a low-commitment starting point — no SaaS contract, no runtime dependency, no data leaves your environment.

Look elsewhere when:

• The codebase is not Laravel (Symfony, Rails, Next.js, or a polyglot monorepo).
• Most UI copy lives in a JS/SPA frontend; you'd want a JS-native extraction tool (i18next-parser, FormatJS) or a TMS CLI that covers both sides.
• You need translation management itself — review workflows, translator comments, screenshots/context, machine translation, or key version control. Localizator extracts; it does not manage translation.
• You already have a TMS with its own repo integration (e.g., Lokalise or Phrase CLI). Running two extraction paths creates duplicate and conflicting source files.
• The org requires legal sign-off on dependencies. The license is reported as NOASSERTION, so verify the actual license terms (the repo is MIT-styled but must be confirmed) before shipping it in a commercial codebase.
• The project is very large or has unusual templating — validate against a subset first; extraction accuracy degrades as custom syntax diverges from Laravel conventions.

Adoption note for the PM: with ~244 stars and zero dependent packages tracked, this is a small, single-maintainer tool (latest release March 2025). Treat it as a velocity helper, not foundational infrastructure — pin the version, keep it in require-dev if possible, and confirm there is a fallback manual process so a stalled maintenance status never blocks a release.

How to Pitch It (Stakeholders)

To executives (30 seconds): Launching in a new language currently means engineers manually hunting for every untranslated string — slow, error-prone, and hard to estimate. Localizator turns that into a single command that produces the exact list of strings we need to translate. That means faster, more predictable market launches, better translation budget forecasts, and no new vendor contract. Cost is effectively zero; the main caveat is that it's a small open-source tool, so we treat it as a workflow accelerator, not a platform dependency.

To engineering: One composer require (dev dependency recommended) and one artisan command produces a complete inventory of untranslated strings across your Blade templates and PHP files, written directly into the standard lang/ structure. No runtime footprint, no config gymnastics, and it fits naturally into CI or a pre-release checklist. Check it against a representative slice of the codebase first, verify the license (NOASSERTION), and expect it to cover Laravel conventions rather than bespoke templating.

To design/content: This gives us a trustworthy answer to "how much copy actually needs translating?" — per screen and per module — so localization scope can be planned alongside feature work instead of discovered at the end.

Decision being asked for: Approve a time-boxed trial on one module to measure output quality and effort saved. If it holds up, adopt it as the standard extraction step in the localization workflow; if the license or maintenance posture is a concern, keep it as an internal tool and pair it with a TMS CLI later.