Filament Translations Google Laravel Package

Technical Evaluation

Architecture fit. This is a plugin-of-a-plugin, not a standalone capability. The dependency chain is three layers deep: Filament panel → tomatophp/filament-translations (the Translations Manager page, scanning, storage, policy) → this package (a single Google-powered "translate" action). That means the architecture decision was already made upstream — if the team isn't on Filament with the parent package installed, migrated, and listing scanned keys, this package has no addressable surface and no fallback path. Where the parent is healthy, fit is good: it adds a UI action to an existing admin workflow rather than introducing a new service, queue, or storage layer.

Integration feasibility. Nominal install is three steps — composer require, filament-translations-google:install, and one ->plugin(...) line in the panel provider — plus optional config and lang publishing. Realistic effort is 0.5–1 engineering day on a stack already running the parent package, and 2–4 days if locales must be mapped, the parent's scan paths/storage driver need tuning, or policy wiring has to be established. Two feasibility positives from the v5 release notes materially reduce risk: the translator is container-resolved (so we can bind a proxy-configured client or a fake for demos and CI), and the action is registered once under Octane. Both are the kinds of details that usually surface as production surprises.

Technical risk. Ranked:

Key questions to resolve before commit.

1. Which strings are machine-translate-now (admin labels, internal errors, low-visibility UI) versus human-review-required (marketing, legal, checkout, compliance)? The tool will not make this call.
2. Where does the action write — directly to lang files, or to the parent's storage driver? That determines our rollback and diff-review story.
3. Does it skip existing non-empty translations, and are :placeholders verifiably preserved on our actual key set? Release notes claim placeholder preservation; validate empirically on 5–10 keys.
4. What volume per day do we expect, and who owns the response when the endpoint rate-limits?
5. Has legal/security accepted a scraping-based third-party endpoint, including any data leaving our network?

Integration Approach

Stack fit. Appropriate for Laravel 12/13 + PHP 8.2+ + Filament v5/Livewire 4 applications where localization is file-based through __() / trans(). Inappropriate for Nova, Backpack, CMS, mobile, or JS-heavy surfaces — the output is PHP language files, and there is no portable workflow to other clients.

Migration path. For an app with hand-maintained language files:

1. Install and configure the parent package; run its scan and confirm keys list correctly in the panel — before touching this package.
2. Commit a clean baseline of lang/ so every machine-generated change is reviewable as a diff.
3. Install this package, publish config and lang stubs, and read the action class in vendor/ — documentation is thin, and the source is the real contract for key selection, skip-existing behavior, and posting.
4. Bind a fake translator to validate wiring in tests/demos without hitting the endpoint.

Compatibility. Pin both packages explicitly with matching majors (tomatophp/filament-translations ^5.0 + this ^5.0, or the v4 line for Filament v4). Treat the parent's config as the source of truth for locales, scan paths, storage driver, and the create ability — verify locale mapping in the published config rather than assuming en_GB resolves. Confirm single registration behavior if we run Octane.

Sequencing. Parent install → locale/policy configuration → translator install with fake binding → 5–10 key pilot on a non-critical locale → QA pass on the resulting diff → gate the action behind a role/create ability → broaden scope → define the threshold at which we escalate to a TMS. Do not enable the action for all admins in step one; the policy gate exists, use it.

Operational Impact

Maintenance. Small dependency footprint but a two-package upgrade chain: a Filament major bump forces the parent, which forces this package. With one maintainer and 6 stars, assume we own the integration — budget a fork-and-patch contingency and track upstream releases rather than relying on responsiveness.

Support. Community-only, no vendor SLA, no enterprise path. We need an internal runbook covering: how to disable the plugin quickly, how to revert a bad language file from VCS, and how a support agent identifies and flags a machine-translated string in a bug report.

Scaling. The action maps roughly to one call per key/line against an unofficial endpoint. That is fine for tens of keys, uncomfortable for hundreds, and unworkable as a continuous pipeline. Recommend explicit batching (5–10 keys per run), off-peak execution, and monitoring failure rate per batch. If translation becomes a recurring, high-volume need, this is the signal to move to a contracted API or a TMS — not to scale this package harder.

Failure modes to instrument.

• Endpoint rate-limits or blocks → partial writes or failed actions; needs detection, not silent retry.
• Silent quality regression on visible strings — the highest-likelihood business-impact failure, mitigated only by a QA gate.
• Locale mapping mismatch producing wrong-language or empty output.
• Placeholder corruption in interpolated strings (:name, :count) — verify per batch, not once at setup.
• Policy misconfiguration exposing the translate action beyond intended roles.
• Upstream major bump breaking the panel at deploy time.

Ramp-up. Engineering: ~half a day to be productive given the parent is in place. Product/ops: 1–2 weeks to establish string-risk segmentation, a QA review step, and a manual-override path — this is the real cost, and it is process work, not code. Budget it explicitly: the package removes manual language-file editing but shifts the review obligation from engineering to product, and without that gate machine translation becomes a quiet quality liability rather than a speed win.