wotz/filament-translatable-tabs
Filament Translatable Tabs adds locale tabs to Filament forms, letting you edit translatable fields for each language in a clean tabbed interface. Simplify multilingual content management in Laravel admin panels.
Architecture fit. wotz/filament-translatable-tabs is a Filament panel plugin, not application infrastructure. Its job is presentation-layer: render one tab per configured locale over translatable form fields (typically backed by spatie/laravel-translatable JSON columns or equivalent). It sits at the outermost edge of the stack — it does not touch routing, persistence, queues, auth, or the public site. Architectural fit remains high if we are on Laravel + Filament and already have a multi-locale content model; zero if we are not. v3.1.0 does not change this: the release is CSS/build-tooling and a cosmetic badge label change, with no new runtime surface on production request paths.
Integration feasibility. Mechanically trivial: composer require, register the plugin in the PanelProvider, apply the provided component/trait to translatable resources. v3.1.0 sharpens the version-alignment question rather than resolving it. Migrating plugin.css to Tailwind v4 is a strong tell that the package now targets the Filament v4 line, since Filament's own asset pipeline moved to Tailwind v4; on a Filament v3 panel (Tailwind v3) the plugin stylesheet may not compile or may render incorrectly, degrading the locale badges and tab chrome rather than breaking function. That is a contained, cosmetic-grade failure — but it must be confirmed before the spike, not discovered in it. Still to verify: exact Filament major constraint, PHP constraint, Spatie trait vs. native JSON casting, and the usual sharp edges — ->required(), ->dehydrated(), per-locale unique rules, reactive fields, nested/relationship forms.
Technical risk. Unchanged in substance, marginally improved in signal. The package remains a low-adoption, single-org project with no evidence of CI/test coverage and no downstream dependents to surface defects, and the stated last release date of 2026-09-15 still reads as registry metadata noise — verify the tag in the repo before pinning. Two data points from this release soften the strict "one maintainer, dead project" read: the changelog is cut against a real compare link (v3.0.0...v3.1.0), implying a genuine semver cadence, and PR #47 lands from a second contributor (@jyrkidn) at a PR number that suggests dozens of prior changes rather than a drive-by repo. Neither substitutes for tests or dependents. The Tailwind v4 migration is a double-edged signal: it indicates the maintainer is tracking current Filament, and it couples our styling to a Tailwind major we do not control. MIT license remains favorable. The composite score (18.25) and low opportunity score (30.34) should be treated as stale pending re-scrape, but are unlikely to have moved enough to change the recommendation.
Key questions.
spatie/laravel-translatable, or does it work with plain JSON columns?Stack fit. Compatible in principle with any Laravel 10/11/12 application running a Filament admin panel and a JSON- or Spatie-backed translation model. v3.1.0 adds a narrower condition: the panel's Tailwind major should match the plugin's. Admin-UX decision, not an architecture decision — still no bearing on public-facing stack, APIs, or data model.
Migration path. Do not adopt fleet-wide. Sequence: (1) confirm the Filament major and Tailwind major of our target panel against v3.1.0 before writing any resource code — this is now a hard gate, not a checklist item; (2) a one-to-two-day spike in a scratch branch against a single low-risk resource such as marketing pages or CMS content, explicitly eyeballing badge/tab rendering, not just function; (3) build-vs-buy against a ~100–200 line internal component and against Filament's native translatable support; (4) if adopted, pin an exact version, vendor or fork it into our namespace, and add a thin internal adapter (a base resource trait) so the package can be swapped without touching every resource; (5) roll out to one resource in production, then expand only if telemetry and editor feedback are clean. Note that this release is a plausible reason to defer rather than adopt if we are mid-migration to Filament v4 — re-evaluate after that lands, when the Tailwind alignment is one-directional.
Compatibility. Validate composer constraints against our pinned Filament version, and separately validate the CSS against our panel's Tailwind version — these are now two distinct checks, and the second is the one v3.1.0 raises. Then test coexistence with other panel plugins already installed (SEO, media library, page builders); form-state collisions between plugins that both manipulate field names remain the most likely functional defect, while CSS conflicts are the most likely cosmetic one. Confirm behavior on Filament minor upgrades, since both form APIs and the asset pipeline churn.
Sequencing. The critical ordering constraint is still fork before production. Because upstream is a low-adoption project, the moment we ship this we implicitly own it; taking the fork early costs little and removes the abandonment failure mode entirely. Add a second constraint introduced by this release: re-run the CSS verification at every Filament/Tailwind major bump, so schedule the fork's dependency-bump chore alongside our own framework upgrades rather than reactively.
Maintenance. Assume we are the maintainers by default. The v3.1.0 signals — a real changelog compare link and a second contributor — justify modeling upstream as low-touch but alive rather than dead, which is a small upgrade from the prior assessment. It does not justify depending on upstream responsiveness. Budget a small recurring cost at each Filament major upgrade; the Tailwind v4 migration means that cost now includes stylesheet upkeep, not just form-API changes. A fork with our own tests converts both from an outage risk into a routine chore.
Support. No vendor, no community, no SLA. We still need a named internal owner and a documented "how this works" note, because onboarding-by-reading-source is the available path when something breaks. The upside of v3.1.0 is that the change is legible and small — a future maintainer can diff one CSS file and one badge label to understand the delta, which is a better handover story than a large opaque feature drop.
Scaling. Effectively free. Admin UI only — no per-request cost on customer traffic, no queue or storage footprint. The scaling dimension that matters is editor usability: tab sprawl becomes a real problem past roughly ten locales, and tab-per-locale hides required-field errors behind inactive tabs unless validation is explicitly surfaced. Named locale badges marginally help orientation at 5–10 locales and do nothing past that.
Failure modes. Ranked by impact: silent translation loss on save (highest — data corruption surfacing weeks later); validation bypass across inactive tabs letting incomplete content publish; breakage on Filament upgrades; CSS/Tailwind-major mismatch causing a degraded or unstyled panel (new, low impact but newly likely given v3.1.0); form-state collisions with other plugins; abandonment with no upstream fix. Each is mitigated by the fork-plus-tests approach and by piloting on content where the stakes are low; the styling failure mode is additionally mitigated by the pre-spike Tailwind check.
Ramp-up. Low for developers already fluent in Filament — under an hour to first working tab set once version compatibility is confirmed. v3.1.0 does not change the learning curve; it adds one verification step (Tailwind major) to the pre-flight. The real cost remains the diligence of verifying save semantics and validation behavior before trusting it with production content.
How can I help you explore Laravel packages today?