Laravel Ai Translator Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. Shipping a new locale is normally gated on translator capacity and per-word vendor cost. This package lets you expand language coverage incrementally (new lang/ file → translated artifact) without a procurement cycle for each locale, so "which markets next quarter" becomes a content and QA decision rather than a budget decision.
• Build vs. buy for i18n tooling. The realistic build is: lang-file parser, provider abstraction, caching/diffing to avoid re-translating unchanged strings, and cost accounting. This package supplies that plumbing (Laravel-native, provider-agnostic). Adopt it as the substrate and spend internal effort on glossary, tone, and review workflow — the parts that are actually differentiating.
• AI vendor strategy and spend governance. v1.7.22 makes OpenRouter the default provider and loads live model pricing. That is a product-level shift: the default onboarding path now runs through an aggregator rather than a first-party vendor, and pricing data is fetched at runtime instead of hardcoded. Use this to support (a) a multi-provider abstraction as policy rather than a nice-to-have, and (b) per-release translation cost estimates in CI as a budget guardrail instead of a surprise invoice.
• Cost-per-locale as a tracked metric. Live pricing means token spend can be attributed per model and per translation run. This enables a real unit-economics number ("cost to add/refresh locale X") that finance and product can reason about, and it makes model-tier tradeoffs (cheap model for drafts, premium model for customer-facing strings) an explicit, measurable decision.
• Tooling for an internal "translation as a build step" workflow. Because it runs inside the Laravel app and CLI, translation can be wired into release or PR workflows for changed lang files only — reducing the manual handoff that typically makes i18n drift.
• CI/maintenance signal, not a feature. The PHPStan memory/parsing fix, added Claude Code workflow, and dependabot bumps indicate an actively maintained repo but also a single-maintainer, single-source dependency. That feeds a build-vs-buy caveat: adopt with a pinning and fallback plan, not as unexamined infrastructure.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel and your translatable surface is primarily lang/ PHP and JSON files — the package's sweet spot. Heavier content (marketing pages, CMS content, long-form docs) needs a TMS, not this.
• You have or want a multi-provider posture. Provider abstraction is the main durable value; it keeps you from hard-coding one vendor's SDK into your release process.
• You need cost visibility. The switch to live model pricing is a genuine reason to evaluate now if per-locale spend forecasting matters to you.
• You accept a review step. Machine translation with no human/QA gate is fine for internal or low-stakes strings; it is not acceptable for legal, billing, or safety-copy. Budget for review or scope the package to non-critical strings.
• You can absorb the maintenance surface. Small team, single primary maintainer, fast-moving AI provider landscape. Plan to pin versions and be ready to swap providers or fork.

Look elsewhere (or wait) when:

• You need translation memory, translator collaboration, reviewer assignment, or vendor invoicing — that is a TMS (Crowdin, Lokalise, Phrase), and this package is a complement at best.
• You are not on Laravel, or your i18n is framework-agnostic across services.
• You have strict data-residency or no-third-party-LLM constraints. Source strings leave your infrastructure; that is a compliance question, not a technical one.
• You want a stable, slow-moving dependency. This release changes the default provider, which is a behavioral change for anyone relying on the previous implicit default — treat upgrades as minor migrations that require a config and credential review, not silent patch bumps.
• Your string volume is tiny and stable. A one-off human translation is cheaper than the integration and review overhead.

How to Pitch It (Stakeholders)

For executives (one paragraph). We evaluated laravel-ai-translator, a Laravel package that automates translation of our language files using AI models. The business case is straightforward: it turns adding a language from a procurement-and-vendor project into an engineering build step, with a measurable cost per locale. The current release (1.7.22) matters for two reasons — it makes OpenRouter the default AI provider and pulls live model pricing, which means our translation spend becomes visible and trackable rather than estimated. The strategic recommendation is to adopt it as the plumbing, not as a finished localization program: we still own glossary, tone, and human review for customer-facing copy. Principal risk is concentration — a small, actively maintained project with essentially one maintainer and a fast-moving dependency on AI vendors. Mitigation is version pinning, a documented provider fallback, and keeping the integration thin. Cost is low and reversible; the value is faster market entry and predictable per-locale spend.

For engineering leads. This is a Laravel-native wrapper that handles lang-file parsing, a provider abstraction, and (as of 1.7.22) runtime model pricing. Treat 1.7.22 as a behavioral upgrade, not a patch: the default provider changed to OpenRouter, so existing installs must check config and credentials before upgrading. Also note the symfony/process ^8.0 allowance — good forward compatibility, but verify it against your pinned Symfony/Laravel matrix. The PHPStan memory and callback-parsing fix removes a real pain point in static analysis runs. Do not adopt the default AI output for customer-facing strings without a review gate; wire translation into CI for changed files only, and cache aggressively to keep both spend and diff noise down. Keep the provider behind our own interface so a vendor change or a project stall costs us a config edit, not a rewrite.

For product managers. Use this to reason about locale expansion cost and sequencing, not to "add AI." Two concrete asks: (1) get a cost-per-locale estimate into the roadmap doc using the live pricing data, and (2) define the quality bar per string class — internal/admin strings can ship machine-translated, customer-facing and legal copy cannot. The vendor-default change is a reminder to keep localization an owned capability with a fallback, not a hidden dependency.