Filament Translatable Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. If your roadmap includes multi-market launch, this package de-risks the CMS/admin layer of that work: it gives editors a tabbed per-locale interface over existing Spatie or Astrotomic translatable models, so localization becomes a content-ops task rather than an engineering one.
• Build vs. buy on admin UI. Translatable form UX (locale tabs, per-locale validation, flag labels) is a recurring custom build in every Filament project with i18n needs. Adopting this replaces roughly days of bespoke Blade/livewire component work with a composer install.
• Backend flexibility as a hedge. Supporting both spatie/laravel-translatable (JSON column) and astrotomic/laravel-translatable (side table) means the package does not force an early, hard-to-reverse schema decision. You can pick per project or per model, and switch via a translationMode enum without ripping out form code.
• Editor enablement and QA scope. Per-locale required validation (requiredLocale, requiredDefaultLocale), per-locale field decoration (currency suffix/prefix per language), and locale labels on field names reduce "content shipped in the wrong language" defects — a real support-cost and brand-risk item, not just a nicety.
• Extensibility for differentiated workflows. Custom actions per locale tab and closures for locales/labels (->locales(fn () => Language::pluck(...))) allow product-specific workflows — e.g., an editorial "mark as reviewed" action per language, or locales driven by a tenant/language table — without forking.
• Adoption signal for scoping. 11 stars and 0 dependents means you are an early adopter, not following a crowd. That is a legitimate decision input: acceptable for an internal admin tool at low blast radius, questionable for a flagship multi-tenant product where you would be the de facto maintainer.

When to Consider This Package

Adopt it when:

• The product already runs Filament 3.x/4.x/5.x and you need translatable admin forms; the README publishes an explicit version-compatibility matrix, which is the main integration risk and it is documented.
• Your Eloquent layer already uses Spatie or Astrotomic translatable traits — this package is the Filament UI layer only; it does not solve storage, routing, or front-end locale switching for you.
• The scope is an internal or back-office admin panel where a broken form field costs editor time, not customer trust.
• You want fast time-to-value: the translatable() macro means a single method call per field, with an escape hatch to the full Translations component for complex multi-field layouts.
• You are comfortable pinning the version and reviewing the changelog on upgrade; releases are actively shipped (latest 2026-11-02) and the repo advertises tests, PHPStan, and Rector in CI — a reasonable maintenance baseline.

Look elsewhere or build in-house when:

• You need this on the storefront/customer-facing path. This is form-component scope only; nothing here addresses translated URLs, SEO metadata, hreflang, or locale negotiation.
• Compliance or procurement requires a support contract or vendor SLA. MIT, single-maintainer, 11 stars, 0 dependents: no vendor to escalate to. That is a hard blocker in regulated or enterprise-procured contexts.
• Your translation model is not Spatie/Astrotomic. Any custom translation schema means adapter work that erases the build-vs-buy saving.
• You are on Filament 2.x. The compatibility table maps 3.x to the old 2.x namespace; older majors are effectively legacy.
• Your content ops need a TMS. If translations flow through Lokalise/Crowdin/Phrase with review states and provenance, a tabbed admin UI is a partial answer — plan the export/import integration as separate scope.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: Our admin panel is built on Filament, and every market we launch requires editors to enter content in multiple languages. Today that means either custom admin code or awkward repeated fields — both slow us down and produce missing-translation bugs. This open-source (MIT, zero license cost) package gives us a proven, tabbed per-language editing experience out of the box, works with either of the two standard Laravel translation libraries so we are not locked into a schema choice, and lets us enforce "this field must be filled in English" rules per language. The trade-off is maturity: it is a small, young project, so we pin the version, keep the integration thin, and treat it as a swappable UI layer rather than a foundation. Estimated saving is engineering days per localization launch, against near-zero cost and low switching risk.

For engineering — what you are actually signing up for: A form-layer package, not a translation platform. Install, publish assets, register the plugin in the panel, set locales and default locale. Models keep using Spatie or Astrotomic (with the package's own AstrotomicTranslatable trait substituting for Astrotomic's). Per-field usage is one ->translatable() call; complex layouts use the Translations component with named instances. Per-locale required rules, per-locale field decoration, and locale-labeled tabs are configuration, not code.

Known sharp edges to state openly, not bury:

• Field-specific methods like required() must be called before translatable(), because the method switches context from the field to the Translations component — an easy source of silent misconfiguration.
• Multiple Translations instances on one form require distinct names.
• Small maintainer base and no dependents: budget for the possibility of forking. Mitigate by isolating usage behind your own form-builder conventions so a replacement is a contained change.
• Pin the major version, and verify the Filament version-to-package-version mapping on every Filament upgrade.

Recommendation: approve as a contained, reversible dependency for the admin panel, with a version pin and an internal note on which models use which translation mode. Do not extend it to customer-facing localization, and do not let it become the reason a translation schema decision is made.