Filament Translatable Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. Whether to ship multi-language content support next quarter is usually gated on engineering cost, not demand. This package collapses the "translatable admin UI" workstream — tabbed locale editors, per-locale validation, locale switchers — into a plugin registration plus a ->translatable() call on existing fields. That turns a multi-sprint item into a days-level item, which changes when i18n can enter the roadmap rather than whether.
• Build vs. buy for admin surface area. The alternative is hand-rolling tabbed locale forms in Filament: replicating field state per locale, wiring spatie/laravel-translatable or astrotomic/laravel-translatable, and re-implementing required-per-locale rules. That is undifferentiated glue code with ongoing maintenance drag. Buy (adopt) is the defensible default if the risk posture below holds.
• Backend lock-in avoidance. Support for both Spatie and Astrotomic backends — configurable globally, per component, or per field — means the CMS data model decision doesn't have to be made in lockstep with the admin UI decision. That's valuable if you already have Spatie-translatable models in production and don't want a migration to get a decent editor.
• Content-ops enablement as a feature. Locale tabs with flags, per-locale prefix/suffix labels, and locale-aware field decoration are not cosmetic. They reduce translator error rate and support burden. If marketing or regional ops teams edit content directly, this maps to fewer "I overwrote the English copy with Polish" tickets.
• Granular rollout by content surface. Because the component can be applied per-form and per-field, and locales can be overridden per component, you can ship i18n for one entity (e.g., product names) without committing the whole admin to a localization model. Good for a phased, measurable rollout.
• Use cases where it fits cleanly: marketing/CMS page content, product catalog copy, category and taxonomy labels, SEO metadata fields, notification/email template bodies — anything where a human edits the same field across N locales in an admin panel.
• Governance signal for the platform team. Low adoption (11 stars, 0 dependents) is itself a data point for the "single-vendor dependency in the admin layer" risk register. Adopting it is a decision to accept a thin-bus factor, ideally with a mitigation plan.

When to Consider This Package

Consider adoption when all or most of the following are true:

• You are on Filament 3, 4, or 5 — the README explicitly covers all three — and are not planning to leave the Filament ecosystem. Support across three major versions is a genuinely strong compatibility signal for a small package.
• Your translation storage is already, or will be, Spatie or Astrotomic translatable models. If you use a bespoke JSON-column or a separate translations table with a custom accessor, you get no leverage.
• The audience is internal or trusted-author admin users. Failures here are contained, observable, and recoverable by the team that owns the panel.
• You can pin the version and budget a fork. With 0 dependents and a small star count, plan for the possibility of maintaining a fork. That budget should be small (the scope is narrow and the surface is well-bounded), but it should not be zero.
• You need the specific differentiators — required-per-locale validation, per-locale field decoration (e.g., PLN suffix vs. USD prefix), custom actions per locale tab. These are the parts that are tedious to hand-roll and are the strongest argument against building.
• Time-to-market outranks dependency purity — e.g., a client deliverable, a launch date, or an internal tool with a fixed deadline.

Look elsewhere or build in-house when:

• The content is customer-facing and revenue-critical with strict uptime or compliance requirements, and you cannot tolerate an unmaintained dependency in the editing path.
• Your translation backend is custom or non-standard (DeepL-managed pipelines, headless CMS, translation-memory systems). The package assumes model-level translation traits; a translation-platform integration is a different problem.
• You need workflow features the package does not claim: translation status/draft states, per-locale review and publish gates, translator assignment, or diffing against a source locale. Those are product-level workflow concerns, not field-level rendering.
• The team is not on Filament. There is no value here outside it.
• You have more than a handful of locales and expect the horizontal tab UI to degrade; validate the UX with a real content set (vertical tabs are available, but very wide locale sets may need a different interaction model entirely).

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on that gives our Filament admin panel a working multi-language editing interface — one tab per language, with per-language required-field rules and language-specific formatting. It replaces what would otherwise be custom engineering work on an undifferentiated part of the product. The trade-off is honest: it's a low-adoption open-source package (11 stars, no downstream dependents), so it's a bet on a narrow, well-scoped dependency rather than a strategic platform. Recommended posture is adopt behind a pinned version for internal admin tooling, with a small fork contingency budgeted — not for customer-facing critical paths without that mitigation.

To engineering: The package handles the tabbed locale UI, locale configuration (global, per-component, per-field), requiredLocale() / requiredDefaultLocale(), per-locale field decoration, and custom per-tab actions. It supports both spatie/laravel-translatable and astrotomic/laravel-translatable, with the mode set globally, per component, or per field — so it doesn't force a data-model decision. Two usage paths: a ->translatable() macro for one-liners, and a full Translations component for grouped multi-field forms. Constraints to respect: field-level methods like required() must be called before translatable(), since the macro switches context to the Translations component; each Translations instance needs a unique name; and php artisan filament:assets is required post-install. Requires PHPStan, Rector, and test CI to be passing on the branch we pin — verify against our PHP and Filament versions before committing.

Recommended next step: a one-sprint spike — install on a branch, apply ->translatable() to two real content models in the existing Spatie setup, and validate with actual translators against our target locale count. Decide on adoption based on that, not on the README.