Filament Translate Laravel Package

Product Decisions This Supports

• Localization roadmap execution: If your product roadmap includes multi-language support and the admin experience runs on Filament, this package collapses a multi-sprint build (translation CRUD UI, per-locale field tabs, save/publish flows) into a composer install. That’s a direct build-vs-buy lever: buy the plugin, spend the saved engineering time on translation quality, glossary tooling, or AI-assisted translation instead of form plumbing.
• Feature scope for translated content types: The new Markdown editor support (1.0.4) widens the addressable use case from plain-text and rich-text fields to long-form, markdown-authoring content — help center articles, blog posts, documentation, CMS pages. This is the difference between “translations work for labels and product names” and “translations work for the actual content product.” Worth re-scoping any localization epic that was previously deferred because editors were markdown-based.
• Editor-consistency decisions: Teams standardizing on MarkdownEditor across content models (for portability, version control, or downstream rendering) no longer have to carve out an exception for translated fields. This removes a real friction point that often forces a “just use a plain textarea for translated fields” compromise, which degrades editorial quality.
• Vendor and dependency posture: Small, young package (1.0.x, single-maintainer-style release cadence, incremental changelog). Fine for internal admin tooling; riskier where translation authoring is business-critical or where an editorial team depends on it daily. Treat as a tactical accelerator, not core infrastructure.
• Migration and exit cost: Data lives in your own models via the standard translatable pattern, so the plugin is a UI layer — swapping it out later is an admin-surface change, not a data migration. Low lock-in, which makes it a cheap bet to trial.

When to Consider This Package

Adopt when:

• You are on Filament (matching major version) and Laravel with spatie/laravel-translatable-style per-locale attributes.
• Your translated fields include or will include MarkdownEditor inputs — now natively supported as of 1.0.4.
• You need an internal, editor-facing translation surface quickly (marketing site copy, catalog content, docs) and translation volume is modest to moderate.
• You want translation editing co-located with the rest of your Filament resources rather than in a separate TMS.

Look elsewhere when:

• You need a full TMS: translation memory, glossary enforcement, vendor/agency workflows, string extraction from code, or automated machine-translation pipelines with review states. This is a field-editing UI, not a localization platform.
• Your translated content is large-scale (thousands of records, dozens of locales) and needs bulk operations, import/export round-trips, or per-locale progress dashboards.
• You are not on Filament, or you are on a Filament version outside the plugin’s supported range — check compatibility explicitly before committing.
• You require vendor SLAs, security review artifacts, or long-term maintenance guarantees. At 1.0.x with a one-line changelog pattern, evaluate the maintainer’s responsiveness and pin your version.

Practical adoption notes: pin the version, smoke-test the MarkdownEditor path in a staging resource before rolling to editors, and confirm your Filament version is inside the supported matrix. Because the Markdown addition arrived as a patch release, verify it behaves as expected in your setup rather than assuming it is purely additive.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost Filament plugin that gives our admin panel a working translation interface without us building one. It turns a multi-week engineering task into a dependency install, and because it only touches the editing UI — not where the data lives — we can walk away from it later without a migration. The latest release (1.0.4) adds support for Markdown-formatted content, which extends it from translating labels and short fields to translating the long-form content that actually matters to the product. Recommendation: adopt for internal admin tooling, pin the version, and keep it out of the critical path until it has more mileage.

To engineering: Low-risk addition — it’s a UI layer over translatable model attributes, so no schema coupling beyond what you already have. 1.0.4 adds MarkdownEditor field support, closing the gap that previously forced plain-textarea fallbacks on long-form content. Two caveats: it’s a young 1.0.x package with a thin changelog, so pin the version and sanity-check the Markdown path in staging; and confirm your Filament major version is within the supported range before wiring it into shared resources. If we outgrow it — bulk translation ops, glossary or TMS integration — the exit is a resource-level swap, not a data migration.