Filament Translations Gpt Laravel Package

Technical Evaluation

Architecture fit. This is a thin extension, not a platform. It registers a Filament action on the parent tomatophp/filament-translations resource and dispatches a queued job that calls an OpenAI-compatible chat completion endpoint and writes results back through the parent's store. The plugin owns no schema, no storage, and no UI of its own. For a TPM that is the headline: the blast radius is one resource action plus one job class, and the removal path is a single composer remove. The corollary is that all the value is contingent on the parent being adopted, on the v5 line, and already rendering its resource in your panel. You are qualifying two packages, and the parent — not this one — is the system of record.

Integration feasibility. High, for the supported matrix only: Laravel 12/13, PHP 8.2+, Filament v5, Livewire 4, parent ^5.0. The installer runs in-process in v5, so it is safe from a container entrypoint or provisioning script — that removes a class of deployment friction that usually costs a day. The public surface is four environment variables plus chunk_size in the published config, and any OpenAI-compatible endpoint is accepted. The real integration work is not the install; it is the four things the package deliberately does not do: run a queue worker, gate dispatch (not just button visibility) behind the policy's create ability, insert a human review step, and instrument spend.

Technical risk. Ranked:

1. Adoption and supply-chain risk — the top item. 28 stars, zero dependents, single-maintainer pattern, and a v4 branch that is mutable and untagged. MIT licensing gives you the right to fork but not the capacity. You are the early adopter and therefore the QA function. Treat "who maintains this if upstream stalls" as a named risk with an owner, not a footnote.
2. Platform coupling. The v5 line implies a coupled four-part platform move. This package will not be your constraint — some neighboring admin plugin will be — but it inherits that schedule risk entirely.
3. Data egress. Every scan ships source strings and values to a third party. This is a legal/DPA decision that must complete before the first production scan, not after. The OPENAI_BASE_URL escape hatch converts it into a routing choice, which is the single most useful property for planning.
4. Cost opacity. No token or spend telemetry, and no skip-if-already-translated check. Re-scans re-pay for unchanged keys. Spend is tied to a button, which means it is tied to a human's judgment.
5. Quality risk. Machine output lands directly in user-facing copy with no glossary, terminology enforcement, or per-locale QA. gpt-4o-mini is fine for bulk fill and poor for brand voice.
6. Silent-failure ergonomics. An unset key means a silent no-op; a missing worker means a dead-looking button with no error; failures land in failed_jobs after a user notification. All three read as "broken feature" to a stakeholder.
7. Data-loss history. Pre-v5, the same key in two groups could be overwritten. If you upgrade, there is a forensic question about existing strings and whether they are recoverable.

Key questions to resolve before committing.

• Which Filament line are we on today, and is the parent package already installed and rendering? Who owns the Filament 5 upgrade, and has the rest of the admin plugin set shipped support?
• Do we have an approved internal OpenAI-compatible endpoint, or is external egress permitted for this copy? Has the DPA review started?
• Who is the named human approver for machine-generated copy, and does the diff live in-app or in a pull request?
• What is the monthly budget envelope, and who watches it? Do we accept re-paying for unchanged keys, or do we fund a pre-filter?
• Is the create ability enforced at dispatch, not merely at render? Has anyone tested with the key revoked in staging?
• Do we accept the v4 branch as a short bridge, or do we block until v5?

Integration Approach

Stack fit. There is exactly one fully supported combination: Laravel 12/13, PHP 8.2+, Filament v5, Livewire 4, parent ^5.0. Anything else is either the maintenance branch or unsupported. Pin the decision in writing so it survives the next sprint planning session.

Migration path. Four parts in order: Filament v5 → Livewire 4 → filament-translations ^5.0 → this package. The breaking surface is the framework majors; this plugin's own API is stable and implies no data migration. If you must stay on Filament v4, treat the v4 branch as a deliberate bridge decision — mirror it internally and track upstream commits rather than pointing Composer at a mutable ref.

Compatibility details that will bite.

• OPENAI_BASE_URL generally needs the versioned path (.../v1), and a self-hosted model may not recognize gpt-4o-mini. Validate model names against the actual endpoint rather than assuming "compatible" means identical catalogs.
• Run php artisan config:cache after config changes and php artisan queue:restart after every environment change — long-running workers hold the config they booted with.
• Route by environment, not by branch: gpt-4o-mini for dev and bulk fill, an internal gateway for staging and any regulated environment.

Sequencing. Five phases, each with a clear exit:

• Phase 0 — qualify the parent. Install filament-translations, confirm its resource renders in-panel, understand its write-back behavior and policy semantics. Do not proceed until this is boring.
• Phase 1 — one locale, one small non-sensitive group. Real worker (Horizon/Redis) wired first. Run the action, watch the queue, diff the table, read the output as a translator would. This single exercise validates auth, chunk sizing, and output quality on the cheapest possible dataset.
• Phase 2 — pilot gating. Grant create to a translator group only; everyone else read-only. Insert the review step you own: translate into a review state, diff in the Filament UI, commit second. Add cost logging keyed to keys × locales × model per scan.
• Phase 3 — broaden. Full locale set, one locale at a time. Tune chunk_size (start near average key length × 50) watching 429s against truncation. Scope scans to changed groups to cap re-pay.
• Phase 4 — harden. Point regulated environments at the internal gateway; wire failed-job alerting; deliberately revoke the key mid-scan in staging and watch the notification, the failed_jobs entry, and your alerts.

CI patterns worth funding: run the suite with OPENAI_API_KEY unset and assert graceful degradation rather than an exception; assert the action registers exactly once (the Octane fix makes double-registration a real regression risk); and run the upstream suite as a baseline before layering changes.

Operational Impact

Maintenance. Small surface, but it tracks the framework closely, so budget re-qualification on every Filament major. Zero dependents means you are the de facto QA for each release. Pin a tag, mirror the repository internally, and put a fork-or-drop review on the calendar — for example, if upstream goes two quarters without a release on your line. A few engineer-days per quarter is the realistic carrying cost.

Support. No vendor support. GitHub issues with a single maintainer. Assign a named internal owner for the integration, the job class, the logging, and the OpenAI contract itself — otherwise the first "the button does nothing" ticket routes to whoever touched it last. The parent package's support posture deserves equal scrutiny, since it holds the data.

Scaling. Scales with queue throughput, not user count. Two levers dominate: chunk_size (large risks truncated or timed-out completions; small multiplies requests into rate limits) and per-locale rather than per-key scanning, so a mid-scan failure produces one bounded, named gap instead of a half-translated matrix. Because writes are keyed by id, the recovery procedure is "fix the cause, re-run the scan" — not "restore the table." Serialize scans across locales, or you will hit provider rate limits with concurrent jobs. Cost scales with keys × locales × re-scan frequency, so it is a forecastable batch cost if you log it and an unbounded surprise if you do not.

Failure modes to plan for.

• Missing key, stale config cache, or worker booted before an env change → silent no-op. Make this the first triage checklist item.
• No worker running → feature appears broken with no UI error.
• API error mid-scan → job fails, user is notified, entry lands in failed_jobs, locale is partially translated. Do not blanket-retry: 401 is a revoked key, 429 wants backoff, 5xx wants a retry.
• Truncated completions from oversized chunks; markdown-fenced answers are accepted but not guaranteed across models.
• Duplicate-key overwrite (pre-v5) — confirm existing strings and verify re-scan cannot clobber human-edited values.
• Octane double registration — assert in CI.
• Spend drift from habitual re-scans of unchanged keys.

Ramp-up. A competent Laravel engineer reaches a first successful scan in under a day; wiring worker, policy gating, review step, cost logging, and failure alerting is roughly a week; folding it into the Filament 5 upgrade makes it a sprint. The longer pole is the translator side: they need a review convention, a one-locale-at-a-time scoping habit, and an explicit understanding that output is a draft, not a shipment. TPM deliverables to close out the decision: a written non-goals list (review queues, glossaries, per-locale QA, and billing are out of scope by design), a cost log, a DPA sign-off, and a stated adoption/exit criterion for the dependency itself.