Filament Translate Field Laravel Package

Product Decisions This Supports

• Sequencing localization: content before interface. The package covers exactly one slice of localization — user-authored content (product descriptions, bios, catalog copy) translated inside a Filament admin form. It does nothing for interface localization (Laravel lang files, date/number formats, RTL) or for structured translation workflow. That narrowness makes it a cheap probe: ship a "write in Dutch, one-click draft into English, human reviews" affordance to a pilot editor group and learn whether multilingual content is genuine customer demand or internal convenience. If editors don't press the button, they won't adopt a heavier translation management system either. The negative signal is as valuable as the positive one, at a fraction of the cost.

• Build vs. buy vs. vendor — and the answer is "vendored pattern." The capability is a form-field action: read the current field value, call a translation provider, write the result into a sibling locale field, mark it machine-generated. The shipped code is small; the interaction design (compact field with a locale switcher, JSON-backed translation column, one action) is the transferable asset. With 10 stars, 0 dependents, and an archived repository last released 2024-10-10, the honest framing is "reference implementation to size and copy," not "Composer dependency." MIT licensing makes vendoring with attribution frictionless. Use the repo to de-risk the estimate, then own the code so the Filament-upgrade and provider-swap risks land on us by design rather than by surprise.

• A scoped feature bet with an instrumentable payoff. The value is editor minutes saved per record and copy-paste into external translation tools eliminated. Instrument it: translate-button clicks per week, records touched, time-to-publish for translated vs. untranslated records, and how often the machine output is edited before save. Heavy editing is a signal about the provider, not about the button. A few weeks with one editor group produces a real keep/kill decision at low cost.

• Forcing a product stance on machine translation. A one-click button is a policy decision wearing a UI costume. Shipping it requires answering: are outputs drafts requiring review or presumed correct? That answer dictates whether you need a visible "machine-translated, unreviewed" marker, an audit record of who translated what and via which provider, approval gating before publish, and a shared editor expectation that unreviewed output is never authoritative. These decisions outlive whichever package or provider you choose.

• Use-case fit and explicit non-fit. Fits internal tooling, marketing/catalog drafts, low-stakes support macros, and teams already on Filament. Does not fit legal, medical, or regulated copy; customer PII crossing to a third-party API without a DPA; bulk locale-wide backfills (a synchronous click is the wrong shape); or terminology-sensitive brands needing glossaries and consistent voice.

• Roadmap non-goal, stated plainly. This is not a foundation for a translation management system. If the roadmap includes reviewer roles, review queues, per-locale cost tracking, translation memory, or glossaries, treat the button as a stopgap with a known expiration date — one interface behind a feature flag that can be replaced wholesale.

When to Consider This Package

Worth considering — as a reference, a fork, or a short-lived internal tool — when:

• You are already on Filament and want a field-level translate action without designing the interaction from scratch. The durable value is the UI pattern: a locale-aware input, array/JSON-backed translation columns, validation and reactive-form integration.
• The need is editor-facing and manual — a human clicks, reads, edits, saves. Volume is tens or hundreds of fields per week, not millions of strings.
• Human review is guaranteed downstream. Translation failures are cheap because someone reads the output before it ships.
• You accept the lifecycle reality: archived, last release 2024-10-10, zero dependents, no security response path. Vendor the source under MIT with attribution, pin and patch Filament compatibility yourself. Do not add an unmaintained package as a Composer dependency you cannot fix.
• You have settled the external-API question: provider choice and commercial terms, key management via config/secrets (never an env value rendered into a form), per-request cost ceiling, rate limits, retry/backoff, response caching so identical strings aren't re-billed, a length guard so a 40KB textarea isn't a surprise invoice, and a written answer on whether the text may leave your infrastructure (DPA, data residency, PII scrubbing).

Look elsewhere, or build in-house, when:

• You need quality and consistency at scale: glossaries, translation memory, brand voice, locale-specific tone, automated QA. That is a TMS category, not a field button.
• You need workflow: translator/reviewer roles, per-locale publish states, approval gates, cost allocation by locale, audit trails for regulated content.
• You are not on Filament, or you are on a Filament major version this archived package predates. Compatibility risk is unowned and will land on you.
• You need batch or asynchronous translation — model and seed backfills, catalog imports, long documents. That belongs in a queue job behind a service interface, not a synchronous click.
• Procurement or security review requires maintained dependencies with a named owner, CVE response, and a support path. A 10-star archived package will not clear that gate, and it isn't worth arguing past it.
• Translation is a core product surface rather than back-office convenience. Core surfaces need an owner, an SLA, and a test suite — which you only get by owning the code.

How to Pitch It (Stakeholders)

To executives — one paragraph. Editors today leave our admin panel to translate copy and paste it back: slow, inconsistent, and invisible to us. This package demonstrates a one-click translate affordance on form fields that removes that round trip and should save a few minutes per record. It is not a strategic bet and not a platform decision. The underlying library is archived, has negligible adoption, and has no maintainer, so I am not recommending we adopt it as a dependency. I am recommending we treat it as a reference implementation — a few engineering days to reproduce and own internally, plus modest per-character API costs, with human review kept firmly in the loop. The decision on the table is whether faster back-office content authoring is worth that small, bounded investment this quarter. It is not a substitute for a real localization strategy, and I would sequence it after we have evidence that multilingual content is a genuine customer need.

To engineering — one paragraph. The pattern is a Filament field action that takes the current field's value, calls a translation provider, and writes the result into a corresponding target field, gated by permission and locale config. Please copy the relevant source into our codebase under its MIT license with attribution rather than adding an archived, zero-dependent package to Composer. Scope it as: a provider abstraction with at least one concrete driver; API key via config or secrets, never a form field; request timeout, retry/backoff, and rate limiting; response caching so identical strings aren't re-billed; a length and size guard so a large textarea doesn't become a surprise invoice; and preservation of HTML, markdown, and line breaks. Add an audit record of what was translated, when, by whom, and by which provider, plus a visible "machine translation — review required" marker on translated fields so nobody ships unreviewed output silently. Provide a clear error state with a manual fallback so editors are never blocked by a provider outage or expired key, and guard against an async translation overwriting a manual edit made while the request was in flight. Write a test around the action with the provider stubbed. Design the call site as one interface behind a feature flag, not sprinkled across resources — if we later want glossaries, review queues, or async batch backfills, that swap should touch one file.