Filament Translatable Tabs Laravel Package

Product Decisions This Supports

• Localization roadmap execution. If the roadmap includes launching one or more new locales (new markets, regulatory language requirements, or partner-facing content), the admin-side translation workflow is a real bottleneck. Per-locale tabs reduce the "which locale am I editing?" error class and shorten the edit cycle for content teams.
• Build vs. buy for admin tooling. This package is a narrow UI convenience layer for Filament forms — likely a few hundred lines that save roughly 1–3 days of form-component work. The decision isn't "buy a platform," it's "spend an afternoon evaluating vs. spend two days building in-house."
• Editor UX feature choice. It forces an explicit decision between three patterns: per-locale tabs (this package), a global locale switcher (Filament-native patterns), or side-by-side/stacked locale fields. Tabs scale better as locale count grows; side-by-side degrades past 3–4 locales. This is a product decision that affects editor throughput and translation completeness, not just code.
• Use cases it enables. Filament-based admin panels for multilingual marketing pages, product/category catalogs, CMS content, and agency client back-offices — anywhere spatie/laravel-translatable (or a compatible trait) is already in the data model and the only gap is the editing surface.
• Translation-completeness metrics. Pairing locale tabs with per-tab completion indicators (or validation) turns "we forgot the German version" from a launch-day surprise into a visible, trackable state — a measurable quality lever. v3.1.0's named locale badges support this by making each tab self-identifying rather than relying on position alone.
• Pilot scope. Because adoption is essentially zero, the rational product move is a single-panel pilot behind an internal flag, with a documented fallback (custom component) if the package is abandoned.

When to Consider This Package

Consider it when all of the following hold:

• You are already on Filament (verify the major version it targets — Filament v3 vs. v4 APIs differ materially) and already storing translations via spatie/laravel-translatable or an equivalent per-locale attribute pattern.
• You have confirmed CSS compatibility for your Filament major. v3.1.0 migrated the plugin stylesheet to Tailwind v4 and named the locale badges — the PR is a styling change with no stated API change, and the 3.x → 3.1.0 bump implies no breaking PHP changes. But Tailwind v4 is the toolchain Filament v4 moved to; on a Filament v3 panel (Tailwind v3 build) a v4-compiled stylesheet can render differently. Load the tab UI in a real panel and eyeball the badges/tabs on both majors before committing. Practically, treat v3.1.0 as a Filament v4-era release unless you verify otherwise.
• The translation surface is admin-only, internal, low blast radius — an editor tool, not a customer-facing runtime path.
• You are willing to vendor or fork it. With 1 star, 0 dependents, and a single maintainer, this is a code snippet with a Composer name, not an ecosystem dependency. Budget an hour to read the source, pin an exact version, and add a smoke test around your translatable forms. Note that the vendored surface now includes a compiled CSS asset, so a styling regression is possible independent of the PHP code.
• You need simple scalar fields (text, textarea, rich editor). Validate explicitly whether it handles repeaters, nested translatable relations, or builder blocks — those are where tabbed translation UIs usually break.
• Your team accepts that upgrades are your problem: a Filament major bump may require you to patch the package yourself. Recent activity (v3.1.0 landed after v3.0.0) is mild positive evidence the maintainer is still engaged, but it does not change the single-maintainer risk profile.

Look elsewhere (or build in-house) when:

• The admin panel is business-critical or has an SLA; a single-maintainer, near-zero-adoption package is the wrong dependency profile for that surface.
• You need translation workflow (draft/review/approve per locale), translation memory, machine-translation hooks, or export/import for translators — this package is a form-layout concern only.
• You need multi-tenant or per-role locale permissions.
• Your locale count is 2 and a simple locale switcher or two stacked fields solves it with zero dependencies.
• Any compatibility doubt exists with your Filament version — the cost of a custom tabbed form component is low enough that uncertain compatibility alone justifies building it. This now includes uncertainty about which Tailwind major the plugin CSS assumes.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, MIT-licensed UI add-on for our admin panel that lets content editors edit each language version of a page in its own tab. It accelerates the localization work already on the roadmap by removing a known editor-friction point, at effectively zero license cost. The latest release (v3.1.0) is a minor maintenance update — a stylesheet modernization and clearer locale labels — which is a modest positive signal that the project is still maintained, and carries no licensing or scope change. The caveat remains maturity: it has essentially no adoption and one maintainer, so we should treat it as an accelerator we own a copy of, not a vendor relationship. Recommended exposure is a single pilot with a two-day in-house fallback if it doesn't hold up.

For engineering (summary): A Filament form-tabs plugin that renders one tab per configured locale for translatable attributes. It is a presentation-layer convenience over spatie/laravel-translatable-style models — no storage, routing, or resolution logic. v3.1.0 migrates the bundled stylesheet to Tailwind v4 and gives the locale badges names; it's a semver-minor with no documented PHP API changes, but the Tailwind v4 move lines the package up with Filament v4's toolchain — so if we're on Filament v3, verify the tabs and badges actually render before adopting, and if we're on v4, this release is the first one that looks intentional about it. Review the source (it's small), pin the version, and vendor it into the repo — including the CSS asset — so a Filament upgrade doesn't block us. Add a form smoke test covering add/edit across at least two locales, and confirm behavior for repeaters/nested fields before committing to it.

For product/content ops (summary): Editors get a tab per language instead of hunting for the right field, which reduces wrong-locale edits and makes missing translations obvious at a glance. The newest version also labels each locale tab explicitly, so editors aren't counting tabs to find German. It changes how the form looks, not how content is stored, so it can be introduced incrementally and removed without a data migration.