Filament Translate Action Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side localization tooling. This package answers a narrow question: should we build a translation button into our Filament admin, or buy/borrow one? For teams already on Filament, adopting it converts a 2–4 week internal tooling task into a composer require plus a config file. That frees engineering capacity for work that actually differentiates the product.
• Whether to make machine translation the default first-draft pipeline. The package makes MT cheap enough to try at the workflow level. The real decision it unblocks is process, not code: do editors write every locale from scratch, or draft in a source locale and machine-translate into the rest for human review? This package makes the second model operationally viable at near-zero engineering cost, which is the prerequisite for measuring whether it's actually faster.
• Locale expansion sequencing. The marginal cost of adding a locale drops sharply when the admin workflow already supports one-click translation. That changes the business case for "should we localize into Portuguese and Polish next quarter" — the incremental ask becomes content review and QA time, not a new tooling build. Use it to make locale roadmap conversations about market priority rather than engineering capacity.
• Translation vendor selection and exit costs. Default provider is Google; the intended integration point is swapping in DeepL or an internal MT service behind an interface. This lets you decide the vendor on cost, quality, and compliance grounds — and reverse that decision later as a config change rather than a rewrite. Treat vendor choice as a reversible decision and say so explicitly in the decision record.
• Data-egress and compliance posture. Every press of the button sends admin content to a third-party translation API. This forces a decision that product, legal, and security need to make together: which content classes are permitted to leave our infrastructure? Internal marketing copy is usually fine; customer PII, contract terms, and regulated content are not. Resolve this before rollout, not after an incident.
• Reducing time-to-publish for localized content. If the admin requires editors to leave the panel, use a spreadsheet, or wait on a translation vendor turnaround, the cycle time is dominated by coordination, not translation. In-panel translation removes that handoff. Instrument time-from-source-draft-to-published-per-locale before and after so the improvement is measurable rather than anecdotal.
• Defining "translated" for launch readiness. Machine output is a draft. This package should not be allowed to silently become your definition of done. Decide per content type whether launch requires human review — brand-critical copy and legal text certainly do; internal admin labels probably don't. Write that rule down; otherwise quality drift is invisible until a customer notices.
• Cost modeling and guardrails. Per-character MT pricing is low but not zero, and the failure mode is editors hammering the button. The engineering guidance — cache by content hash, batch, never fire on keystroke — is really a product requirement about acceptable spend. Set a monthly ceiling and a caching expectation as acceptance criteria, not an afterthought.
• Scope discipline. This is internal admin tooling with a small blast radius. It should be evaluated and funded as an operational efficiency improvement, not a customer-facing feature. That framing keeps it out of the headline roadmap and out of the critical path for release commitments.

When to Consider This Package

Consider it when:

• The stack is Laravel with Filament (v3/v4 era) and the admin panel is where content is actually authored. If editors don't live in Filament, the package solves nothing.
• Translatable content is modeled either with spatie/laravel-translatable (one JSON per attribute) or with plain per-locale columns. Both are supported; the integration is cleanest with the former.
• You have at least two locales and a small-to-mid content team — roughly a handful of editors across a few resources — where the coordination overhead of off-panel translation is the dominant cost.
• The content classes involved are cleared for third-party MT: marketing copy, product descriptions, internal labels, SEO metadata. Not PII, not legal text, not customer-authored content under confidentiality obligations.
• You can absorb single-maintainer dependency risk. At ~38 stars and a last release in October 2024, this is a small-footprint package with a limited contributor base and uncertain cadence against future Filament majors. Acceptable if you can vendor it or replace it, and if you pin the Filament major explicitly.
• Your team will actually do the operational work: strip HTML before sending, chunk long fields, map locale codes explicitly, re-validate after fill, and place the action only on source-locale fields so it can't overwrite reviewed content.
• Machine translation quality is good enough as a starting point for human review, and reviewers are in the loop. For closely related language pairs this is often a real time-saver; for distant pairs it can create cleanup work that exceeds the benefit.

Look elsewhere when:

• The stack is not Laravel/Filament. There is no partial fit here.
• Localization needs translation management capabilities: approval workflows, glossary enforcement, translation memory, per-string audit trails, role-separated reviewer permissions, or vendor SLAs. These are organizational requirements a form action cannot satisfy, and retrofitting them is more work than adopting a real TMS.
• Content volume is high or fields are long. Article bodies, documentation, and rich text need an asynchronous pipeline with a job queue, chunking, and a real CAT workflow. The inline action is for titles, taglines, and short meta fields.
• Regulatory or contractual constraints prohibit sending content to external MT providers, and you don't have an approved internal translation service to bind in.
• Localization is a strategic differentiator with its own quality bar, terminology program, or brand voice standard. In that case bespoke tooling is justified and this package is a temporary bridge at best.
• The admin surface is security-sensitive enough that any third-party package needs a formal review cycle longer than the value delivered.
• You need someone to call when it breaks. There is no support contract, and the release history suggests maintenance mode rather than active development.

How to Pitch It (Stakeholders)

Executives. This is a small, MIT-licensed helper for our admin panel that lets content editors translate fields into other languages without leaving the tool. It is an internal efficiency play, not a customer-facing feature, so the downside is bounded: if it doesn't work out, we remove a composer dependency. The upside is a measurable reduction in the time it takes to get localized content live, plus a lower marginal cost for each additional locale we choose to support — which makes future market expansion decisions about market priority rather than engineering bandwidth. Cost is a per-character machine translation fee, controllable with caching and a monthly cap. The main thing we need a decision on is which content we're comfortable sending to a third-party translation API. Recommendation: pilot on internal, non-sensitive content with two locales and human review before publishing, then measure.

Engineering. Adopt as a thin, replaceable layer, not as infrastructure. Pin the Filament major and verify compatibility before upgrading; the v1.2.x line targets the v3/v4 era, and mixing majors produces confusing Livewire mount errors rather than a clean Composer conflict. Read source and target locales from shared config so the panel and the action can't drift, and wrap the repeated suffixAction(TranslateAction::make(...)) in a helper — at fifteen translatable fields this is the difference between a one-line change and a scavenger hunt. Bind the translator behind an interface so a provider swap is a config change. Keep the action for short fields and dispatch a queued job for long copy; inline translation of a long body will stall the round trip. Treat output as a draft: write only into empty target locales on edit forms, re-validate after fill because translated values routinely exceed maxLength, and surface errors on the target tabs. Strip HTML tags before sending, chunk anything approaching ~5k characters, and map locale codes explicitly — pt versus pt-BR and zh-CN versus zh-TW produce plausible-looking wrong-language output, which is the worst failure mode here. Log the raw provider response alongside the detected source language. Note the maintenance risk: low star count, last release October 2024, uncertain cadence against future Filament versions — keep the integration shallow enough that forking or replacing it takes days, not weeks.

Product and Operations. Frame this as a workflow change with a quality gate, not a feature launch. The win is removing the leave-the-admin-panel handoff from the translation cycle; the risk is that "the button filled it in" quietly becomes the definition of done. Set the rule now: machine output is a draft, human review is required for brand-critical and legal content, and reviewers work locale by locale with the source visible. Instrument the metrics that justify the investment — time from source draft to published per locale, percentage of locale fields complete at launch, reviewer throughput, and monthly MT spend against the cap. Pilot with one resource and two locales, confirm the translated fields are actually better than what editors were producing before, and only then roll out. If the pilot shows reviewers spending more time correcting output than authoring, stop — the package works, but the language pair doesn't.