Filament Translatable Laravel Package

Technical Evaluation

Architecture fit. The package is a Filament panel plugin that adds translatable form-field behavior through two complementary surfaces: a translatable() macro that wraps any existing Filament field, and a standalone Translations component for multi-field groups. This is idiomatic Filament 3/4/5 extension design (panel plugin registration, macro injection, asset publishing), so it slots into an existing panel with minimal architectural disruption. It is deliberately agnostic at the storage layer, delegating persistence to either spatie/laravel-translatable (JSON columns) or astrotomic/laravel-translatable (side tables), which means your data model decision is orthagonal to adopting the UI package. That separation is the strongest design property here.

Integration feasibility. Composer require, php artisan filament:assets, add FilamentTranslatablePlugin::make() to the panel provider, configure locales(), defaultLocale(), and translation mode. For Astrotomic mode you must swap the vendor Translatable trait for the package's Happenv\FilamentTranslatable\Traits\AstrotomicTranslatable — a non-obvious substitution that needs explicit review. Effort is roughly a half-day for a first resource and two to three days to standardize conventions across a panel.

Technical risk. The dominant risk is provenance, not code quality. The score (21.8), 11 stars, and 0 dependents mean this is effectively unproven in production anywhere. The README's own metadata is inconsistent: the Packagist name is happenv-com/filament-translatable while the GitHub repo is happenv-com/filament-translatable, the description reads "ilament Translatable," and the latest release is dated 2026-10-16 — a future date that signals either a versioning anomaly or unreliable registry metadata. Supporting Filament 3, 4, and 5 simultaneously implies branch maintenance (v3 vs v4 branches, per the version-mapping table, with a namespace change between 2.x and 4.x), which is a real upgrade hazard. Single-maintainer concentration risk is high. The MIT license is the mitigation: forking is viable if the maintainer goes dark.

Key questions for the maintainer / engineering spike.

• What is the intended support window and cadence per Filament major version, and how are the 3.x/4.x/5.x branches kept in sync?
• Why does the Astrotomic mode require a custom trait rather than the vendor trait — what does the wrapper add, and is it forward-compatible with Astrotomic releases?
• How are translations validated and persisted across tab switches — is there any risk of silent loss when a field is left blank in a non-default locale?
• Does the translatable() macro collide with any macro names already registered by other Filament plugins in our panel?
• What is the behavior inside nested structures — repeaters, builders, relation managers — and in non-form contexts (tables, infolists, actions)?
• Is there a tested upgrade path when Filament ships a breaking release (Filament has historically done major versions annually)?

Integration Approach

Stack fit. Laravel + Filament 3/4/5, PHP 8.x, with spatie/laravel-translatable as the default and recommended backend. If the application already uses Spatie for other models, adoption is nearly free. Astrotomic is viable but only if the team already runs side-table translations; do not adopt Astrotomic for this package.

Migration path. Two distinct cases. Greenfield resource: use the Translatable trait + JSON columns from the start, no data migration. Existing localized content: you must first decide the storage target. Moving to Spatie means a schema change (per-locale columns → single JSON column) with a backfill; staying on Astrotomic means adding the package trait and verifying column/relation naming. Do the data migration as a separate, reversible step before the UI change — never in the same PR.

Compatibility. Verify the Filament major against the version-mapping table (Filament 3 → package 2.x with the old namespace; Filament 4/5 → 4.x). Pin the package exact-version in composer.json and require an explicit PR to bump. Check PHP constraint overlap with the rest of the dependency tree, and confirm composer.lock reproducibility in CI before rollout.

Sequencing.

1. Spike (1–2 days): stand up the plugin on a low-traffic admin resource, exercise translatable(), Translations, required-locale validation, and flags in light and dark mode.
2. Data decision: lock the translation backend and execute any schema/backfill migration independently.
3. Pilot resource: ship one fully localized resource behind an internal flag; instrument for save/validation errors.
4. Codify conventions: publish an internal pattern (macro-first for single fields, Translations for grouped fields; required-locale rules; label conventions) so the team doesn't diverge.
5. Breadth rollout: resource-by-resource, not a big-bang.
6. Exit criteria gate: reassess before rollout exceeds three resources — if the maintainer has gone silent or Filament has moved a major version, fork or replace.

Operational Impact

Maintenance. Expect to own the risk. Pin versions, monitor the repo for stale issues, and keep a fork-ready branch in the plan from day one. The MIT license makes this cheap; treat the package as "vendored with upstream intent" rather than a trusted dependency. Any Filament major upgrade becomes a scheduled investigation, not a routine bump.

Support. No commercial support, no SLA, single maintainer, community issues only. The README is unusually thorough for a package this size — screenshots, both backends, per-component and per-field overrides, edge cases called out — which partially compensates. Budget for a senior developer to answer the team's own questions.

Scaling. Rendering overhead is negligible; the Translations component is fundamentally a tabbed form wrapper. The real scaling constraint is UX and validation surface: each additional locale multiplies tabs, fields, and required-locale rules. Beyond ~5 locales the horizontal tab layout degrades — switch to ->vertical() and consider segmenting locales by market. Astrotomic mode adds per-locale relation queries, which shows up in admin list/relation-manager views at volume.

Failure modes to watch.

• Macro collision: another plugin registering translatable() on Filament fields — fail at boot, visible immediately.
• Silent translation loss: blank non-required locales overwriting existing data on save; validate in the pilot.
• Locale config drift: plugin locales() diverging from app.locale/fallback_locale and from the stored JSON keys, producing empty tabs that look like data loss.
• Asset publishing: filament:assets skipped or stale after deploy, breaking flags and tab styling in production.
• Filament major bump: namespace/API breakage across the 2.x→4.x boundary; pin and test.
• Unmaintained upstream: no fix path without a fork.

Ramp-up. Low for anyone with Filament experience — under a day to productive use, given the README quality. The non-obvious friction points are the Astrotomic trait substitution, the "set field methods before translatable()" ordering caveat (documented, but easy to miss), and the context switch from field to Translations component after the macro call. Capture all three in the internal pattern doc; they are the most likely sources of review-cycle churn.

TPM recommendation. Adopt for pilot only, contingent on a successful spike and a documented fork plan. The functionality is well-targeted and the design is clean, but 11 stars and zero dependents mean the package is unvalidated at scale. Gate broad rollout on the pilot and on a maintenance review at the next Filament major release — if upstream has not kept pace, fork (MIT permits it) or replace with a thin in-house wrapper over Spatie, which is a bounded effort given the small API surface (translatable() macro plus Translations component).