Laravel Translation Laravel Package

Product Decisions This Supports

• Localization roadmap / market expansion: decides whether shipping locale N is a 2-day config change or a 6-week engineering project. The package automates the string-extraction side of that estimate.
• Build vs. buy on translation plumbing: the real choice is in-house artisan commands + spreadsheet exports vs. this package + POEditor vs. a TMS with a native Laravel SDK (Crowdin, Lokalise, Phrase). This package is the cheap middle path; quantifying the in-house cost (roughly 1–2 engineer-weeks to build and maintain a scanner plus sync) is the decision input.
• Vendor selection: it effectively commits you to POEditor as the translation management system. That is a real, sticky decision — translators, glossary, and memory live there — so treat it as a TMS selection decision, not a utility-library decision.
• Translation coverage as a release gate: the scanner makes missing/unused keys visible, enabling CI checks like "no untranslated keys in de, fr before release" and a coverage metric per locale you can put on a dashboard.
• Team topology: it removes developers from the translation loop. Product/localization owners edit in a web UI; engineers only run pull commands. That changes headcount assumptions for launching a new market.
• Scoping which surfaces are translatable: works well for PHP/Blade strings (__(), @lang, trans()). It does not solve JS/Vue/React i18n or per-tenant/database-driven content — those need separate decisions, and knowing that boundary early prevents a false "localization is done" signal.

When to Consider This Package

Adopt when all of these hold:

• Laravel app with translations in lang/ files, PHP 8+, modern Laravel.
• POEditor is already in use, or you're choosing a TMS and POEditor's pricing fits (its per-word model is friendly at small volumes).
• You want translations versioned in Git but edited by non-engineers.
• No dedicated localization engineer; a developer running two artisan commands per release is acceptable.

Look elsewhere when:

• Your TMS is Crowdin/Lokalise/Phrase, or you need in-app translation management, runtime overrides, or per-customer content (use a DB-backed solution like spatie/laravel-translation-loader).
• Frontend strings dominate — this scans PHP/Blade, not your SPA bundle.
• You need ICU message format, pluralization rules, or translation memory enforced at runtime.
• Vendor-risk tolerance is low: ~133 stars and a small maintainer surface means thin community support. Mitigate by treating it as dev-only tooling (it is not in the request path), pinning the version, and keeping the sync commands thin enough to replace.
• Compliance/security review forbids third-party upload of source strings to an external SaaS.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed integration that shortens time-to-new-market from weeks of engineering to a per-release routine. It connects our Laravel codebase to POEditor so product and marketing can edit copy directly while engineers keep everything in version control. Cost is essentially zero; the decision that matters is whether POEditor is our translation system of record.

For engineering: This is dev/CI tooling, not runtime code — no production dependency, no request-path risk. It scans for translation keys and syncs them with POEditor via artisan commands, which we can wire into a release checklist or CI job. Scope is PHP/Blade only; plan separate tooling for JS strings. It's small and single-maintainer, so we pin the version and keep a one-day fallback to our own scanner.

The ask: approve a two-week pilot on one product and two locales. Success metrics: percent of strings translated per locale before release, translation turnaround time, and zero engineer hours spent on string wrangling after week one. If the pilot doesn't hit those, we fall back to manual export or a TMS with native Laravel support — both still open.