Filament Translatable Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. A first-class TranslatableInput (modal or inline) and TranslatableEntry (expandable or modal) turn "add more locales" from a schema-and-UI project into a configuration change. This is the deciding input for whether to ship locale #3–#8 next quarter or defer.
• Build vs. buy on admin i18n. The default alternative is hand-rolling tabs/repeaters over spatie/laravel-translatable plus a custom infolist renderer — typically days of work per Filament major upgrade. This package collapses that to a plugin registration and a per-panel config file.
• AI translation as a product feature, not a side project. Generate all translations in a single API call via laravel/ai is the commercially interesting line item: it makes machine-translated draft content viable for CMS-style admin panels, and it lives behind laravel/ai so provider/model choice stays a config decision rather than a code decision.
• Editor UX tradeoff calls. Choosing modal vs inline for the form field, and inline (expandable) vs modal for the infolist entry, is a real product decision about whether translators work field-by-field in context or locale-by-locale in a focused pane. Having both means the decision is reversible without a rewrite.
• Content-density decisions in read views. ->lineClamp() on TranslatableEntry is small but it's the difference between a usable multi-locale review table and an unreadable one; it supports decisions about showing translation status in list views.
• Framework currency. Filament 4 & 5 compatibility means this doesn't pin your upgrade path — relevant if you're planning a Filament major bump this year.

When to Consider This Package

Adopt when most of these hold:

• You run Filament admin panels with 2+ locales and the translation UI is currently hand-built or absent.
• You already use, or are willing to adopt, spatie/laravel-translatable-style translatable attributes and laravel/ai for machine translation.
• You want per-panel language configuration (different panels legitimately have different locale sets and source locales) rather than a single global config.
• Your translators are internal staff or content editors who benefit from AI-generated first drafts — not a professional CAT-tool workflow with TM/glossary requirements.

Look elsewhere or wait when:

• Version risk is unacceptable. This is 0.1.0 — the first public release. No upgrade path, no deprecation history, no evidence of production adoption. Treat it as an evaluation, not a commitment, for anything revenue-critical. Expect breaking changes before 1.0.
• You need translation workflow, not translation input. No review/approval states, no translator assignment, no export to XLIFF, no translation memory. If localization is a governed process, this is one layer short.
• AI translation is out of policy scope. Sending customer or regulated content to a third-party model provider needs legal/DPA sign-off. The laravel/ai indirection helps (swap provider, or disable), but confirm the toggle story before committing.
• Filament 3 is still in your fleet — this targets 4 & 5.
• You need high-cardinality locales (20+) where modal-per-field editing becomes tedious and a dedicated translation surface is warranted.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that removes a recurring engineering tax on every new market we open. Adding a language becomes a config change in the admin panel rather than a build project, and AI-generated first drafts cut the cost and latency of getting a new locale to "reviewable" from days to minutes. The tradeoff is maturity: it's a 0.1.0 release, so we should pilot it on one panel, not standardize on it company-wide.

To engineering: Filament form field and infolist entry for translatable attributes, with modal or inline presentation modes, per-panel plugin configuration (languages, source locale, AI provider/model), and a single-call AI translation path through laravel/ai. Supports Filament 4 and 5. What it replaces is our bespoke tabbed-repeater pattern that we rewrite on every Filament major. What it does not give us is a translation workflow, storage abstraction, or test/coverage guarantees we can point at — so scope the pilot to one panel, pin the version, and budget for an abstraction layer in case we need to swap it out before 1.0.