Nova Ai Translator Laravel Package

Product Decisions This Supports

• Localization workflow in the admin surface. This package turns "translate this record" into a one-click Nova Action, which supports decisions about whether to expose content translation to non-technical operators (editors, regional GMs) rather than routing every translation request through engineering or a separate TMS.
• Build vs. buy for AI translation plumbing. It packages the SharpAPI.com integration, so the decision becomes "buy a managed translation API and wrap it in a Nova Action" versus "build our own provider abstraction (OpenAI/DeepL/Google) plus queueing, retries, and audit logging." The package is evidence that the thin-wrapper path is cheap; the real cost is in review workflows, glossary/terminology control, and cost governance — none of which ship here.
• Roadmap scoping for multi-locale content. Useful as a spike/prototype to answer "how fast could we get translated product copy, CMS pages, or support macros into a second language?" before committing to a full localization roadmap with human-in-the-loop review. v1.1.2 confirms multi-record selection works end-to-end, so a backfill demo (select 20 records, translate, review) is now a credible prototype rather than a single-record demo.
• Internal tooling vs. customer-facing feature. Because it lives in Nova (an internal admin panel), it supports decisions about operator-facing translation tooling rather than end-user auto-translation — a meaningfully different risk profile (no runtime dependency, no user-visible latency or quality surprises).
• Vendor concentration risk. With SharpAPI.com as the sole backend, adopting this is effectively a decision to accept a third-party dependency for an internal convenience feature; that's fine for back-office tooling, questionable for anything on a revenue path.
• Tolerance for early-stage maintenance. The v1.1.2 fix addressed a batch-integrity defect: one already-complete record caused every subsequent selected record to be silently skipped. That is the kind of failure that produces "the translation ran" tickets with no translation — a signal about maturity, and useful evidence when arguing for owning the implementation rather than depending on it.

When to Consider This Package

Consider it when all of the following hold:

• You are already on Laravel Nova 4 and your team is comfortable installing third-party Nova Actions. This package is worthless outside Nova — it is not a general Laravel translation library.
• The use case is internal, human-supervised translation: an editor selects one or more records, triggers an action, and a human reviews the output before publishing. No automated publish path.
• You want to validate demand cheaply — a one-afternoon prototype to show stakeholders "here's what AI-assisted translation in our admin feels like" before funding a real localization initiative. Multi-select now works for small backfill demos, but treat the result as a demo, not a data migration.
• You have (or will get) a SharpAPI.com account and are comfortable sending content to that vendor, including any data-residency or DPA review that implies.
• Your volume is low and bursty (dozens to low hundreds of records), where in-request action execution and per-call API pricing are acceptable. Pin ≥ v1.1.2 if you select multiple records — earlier versions can skip records silently.
• You can tolerate per-record skip semantics without a ledger: the action reports how many records were skipped, but there is no per-record record of what was translated, by which model, or at what cost. Verify the skip counts against your selection before trusting a bulk run.

Look elsewhere when:

• Adoption signals matter to you. 4 stars, 0 dependents, and a single-maintainer commercial-backend package is a red flag for anything load-bearing. v1.1.2 is a genuine correctness fix, but it also shows the batch path shipped with a data-skipping bug — treat it as a reference implementation, not a dependency.
• You need queued translation at scale, glossary enforcement, translation memory, locale fallback rules, or per-field diffing. Multi-select exists, but it executes the batch inside the action rather than as queued jobs, so long selections still mean a long request and no retry/resume story — that's a TMS or a purpose-built pipeline, not a Nova Action.
• You need provider flexibility (swap OpenAI ↔ DeepL ↔ self-hosted) or cost controls per team/project.
• You are not on Nova, or you're on Nova 5+ and the Action API has drifted — verify compatibility rather than assuming.
• Compliance requires no third-party subprocessor for content, or you need on-prem/self-hosted inference.
• You need auditability: who translated what, with which model, at what cost, and which version was approved. This package does not appear to provide that ledger, and the new "N records skipped" response is a transient message, not a stored record.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on that puts a "Translate" button inside our existing admin panel, powered by a commercial AI translation API. It is not a localization strategy — it's a cheap way to demonstrate one. Cost is a few hours of engineering plus per-character API fees, and there is no lock-in beyond the API key. The latest release (v1.1.2) fixes a bug where a single already-translated record caused the rest of a multi-record selection to be skipped, so a small bulk backfill demo is now viable — but note that quality control, terminology consistency, and an audit trail are all still ours to build. Recommendation: fund a short spike to measure whether editors actually want in-admin translation before we budget for a real localization platform. Do not put it in front of customers.

To engineering: It's a Nova 4 Action wrapping SharpAPI.com — a thin adapter, not infrastructure. v1.1.2 is a correctness fix on the multi-select path: previously the action returned early when any selected record was already fully translated, silently skipping the remainder of the batch; now that record is marked finished individually and the rest proceed, with a skip count surfaced in the response. That's the right behaviour, but it also tells you the batch loop had no per-record error isolation, no idempotency ledger, and no way to verify what was actually skipped after the fact. If we adopt the idea, we should own the implementation: a queued job per field/locale, a provider interface so we can swap vendors, a translation record table for audit and cost attribution, and a review/approve state before publish. The package is best used as a two-hour spike to pressure-test the UX, then retired. Note the maintenance risk: 4 stars, 0 dependents, one maintainer, and a hard dependency on a paid third-party service — we should not take a production dependency on it.

To the localization/content team: It would let an editor select a record in Nova — or a handful at once — and get machine translation drafts in seconds, with a human still responsible for approval. Skipped records are now reported rather than silently dropped, so a small bulk run is safer than it was. It won't handle terminology consistency, translation memory, or multi-locale workflows — so expect it to complement, not replace, whatever we use for the real program.