Filament Translatable Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. Filament Translatable is the piece that decides how cheaply we can ship a multilingual admin experience. If our content models already use spatie/laravel-translatable, this plugin turns that schema decision into working locale-tabbed forms and per-locale table columns without bespoke Blade/Livewire work — which lets us commit to "N languages at launch" instead of "N languages post-launch."
• Build vs. buy for admin i18n UI. The alternative is hand-rolling translatable field wrappers, locale switchers, and fallback logic inside our Filament resources. That is real, recurring engineering cost (and a classic source of subtle bugs around fallback locale and dirty-state on save). Adopting the package converts that into a dependency line in composer.json.
• Panel upgrade timing (the v3.2.0 news). v3.2.0 adds Filament v5 compatibility. That is the decision-relevant item in this release: it means our Filament v5 migration is no longer blocked by our i18n layer, and conversely it signals the maintainer is tracking Filament majors. If we are still on Filament v3/v4, this release is not automatically for us — we must check whether v3.2.0 widens the constraint or drops older majors, and pin accordingly.
• Scope boundary: admin vs. customer-facing. This is an admin-panel translation tool. It does not solve public-site locale routing, hreflang, machine translation, or content-review workflows. Treat it as an internal-tooling decision, not a product-localization strategy.
• Roadmap risk input. Single-maintainer, community package with a small dependency footprint. That is fine for an admin surface; it would be a poor foundation for a revenue-critical, customer-facing translation pipeline.

When to Consider This Package

Adopt when most of the following hold:

• We are on Filament (v5 for this release; verify the constraint before upgrading if we are on v3/v4) and our translatable content lives in spatie/laravel-translatable-style JSON columns.
• The translation need is admin/editorial UI — editors entering per-locale copy in a resource form, reviewing translations in a table — not end-user localization.
• We have a modest locale count (roughly 2–10) where a tab-per-locale or field-per-locale UI is genuinely usable. Beyond that, tabs become a UX problem and the real need is a translation workflow tool.
• We want to avoid maintaining custom field components and are comfortable owning a thin, community-maintained dependency.
• Our team is small enough that "one more Composer package" is cheaper than "one more internal package to maintain."

Look elsewhere when:

• We need translation management — TMS integration, vendor handoff, review/approval states, per-string status. That is a different product category; this plugin will not get us there.
• We are not on Filament, or are on a Filament major this release does not support. Verify the composer.json constraint on the tagged release rather than relying on the changelog headline.
• Our content model does not use spatie-style translatable attributes; retrofitting the data model is the real project, not the plugin.
• We require an SLA, vendor support, or a security disclosure process with named owners.
• Translation is customer-facing and revenue-critical, where a single-maintainer dependency is an unacceptable bus-factor.

How to Pitch It (Stakeholders)

For executives (one paragraph). We can support a multilingual admin experience at roughly the cost of a Composer dependency instead of a multi-sprint internal build. This package is the standard Filament plugin for editing translated content, and the new v3.2.0 release confirms it tracks Filament v5, so it will not block our panel upgrade. The exposure is low — it touches internal tooling, not the customer-facing product — but it is community-maintained by a single author, so we should pin the version and treat it as a dependency we monitor rather than one we assume is permanent.

For engineering. Drop-in Filament plugin that wires spatie/laravel-translatable models into locale-aware form fields and table columns, removing the custom field wrappers and locale-switching logic we would otherwise own. v3.2.0's headline is Filament v5 support; the rest of the release is Dependabot hygiene (checkout, git-auto-commit-action, fetch-metadata), so the only thing to actually validate is the Filament version constraint. Before merging: confirm our filament/filament constraint intersects with what v3.2.0 declares, confirm whether the new tag still supports our current major if we are mid-migration, and pin the version explicitly. Also confirm the package's own spatie/laravel-translatable requirement matches the version we already run, and that our fallback-locale configuration is exercised in the form save path — that is where these plugins tend to have edge cases.