Filament Translatable Fields Laravel Package

Technical Evaluation

Architecture fit. The package is a thin UI adapter, not an application-layer dependency. It sits between two established libraries — Filament's form/table API and spatie/laravel-translatable — and adds no persistence of its own, no schema, no service provider surface beyond registration and a config file. That is the right shape for this problem: translations stay in the model's JSON column under spatie's conventions, and the package only controls how those keys are presented and collected in the admin panel. It is additive and reversible; removing it leaves data untouched. It fits the TALL-stack admin surface only — it has no role in public-facing rendering, APIs, or localization delivery.

Integration feasibility. Low effort per resource. Typical path: composer require outerweb/filament-translatable-fields, optionally publish the config to declare the locale set, then wrap existing form fields in the package's translatable wrapper (or apply its field macro, depending on the installed version). No database migration is required if models already use the HasTranslations trait and JSON columns. Realistic estimate: a half-day spike to validate against our Filament version, then one to two hours per resource thereafter.

Technical risk. The dominant risk is version coupling. The package targets a specific Filament major; Filament's form API has historically broken between majors, and a 36-star package with a single maintainer will lag on upgrades. Secondary risks: (a) three sources of truth for locales — package config, spatie config, and our app config — which drift silently; (b) per-locale validation is not automatic, so "required" and length rules must be wired explicitly or partially translated records reach production; (c) table columns and global search over JSON translations are typically out of scope and need separate handling; (d) published Blade views create upgrade friction because local overrides mask upstream fixes; (e) near-zero adoption (0 dependents) means no field-tested edge cases and a bus factor of one. The low opportunity score reflects this — it is a convenience, not a capability we cannot build in-house in a day.

Key questions.

• Which Filament major are we on, and is a v4 upgrade on the roadmap within the next two quarters?
• Does the current release support per-locale validation rules and per-locale required?
• Which field types are supported — plain inputs only, or RichEditor, FileUpload, Repeater, Select?
• Does it respect spatie's fallback_locale and surface fallback values in the UI?
• What is the maintainer's release cadence and typical issue response time?
• Are views publishable, and if so, can we avoid publishing them?

Integration Approach

Stack fit. Direct match if the admin is Filament and models already use spatie/laravel-translatable. If either condition is false, the package is the wrong lever — fix the underlying choice first.

Migration path. Two cases. If translation columns are already JSON (spatie's default), integration is purely presentational and carries no data risk. If the codebase currently uses per-locale columns (name_en, name_nl), a JSON consolidation migration and model refactor must land first; the package does not help with that and should not be sequenced before it. There is no lock-in either way: the package writes through spatie's standard accessors, so uninstalling is a composer removal plus reverting field wrappers.

Compatibility. Before committing, verify composer constraints for PHP, illuminate/*, filament/filament, and spatie/laravel-translatable, and confirm the package registers as a Filament plugin or via a service provider on our version. Collapse locale configuration to a single source (an app-level config or enum) and have the package config read from it, rather than maintaining a parallel list.

Sequencing.

1. Branch spike: install, register, wrap two or three field types on one low-traffic resource.
2. Validate save/load round-trips, fallback behavior, and per-locale validation.
3. Standardize locale source, then codify the wrapper pattern in a base resource or internal helper so future swaps are single-file.
4. Roll out resource by resource, starting with content types that actually need translation.
5. Document the pattern and add a regression check tied to Filament version bumps.

Operational Impact

Maintenance. Small footprint, but we own the upgrade tail. Budget a review of the package on every Filament major and every spatie minor that touches translation storage. Isolating usage behind an internal wrapper or base resource converts a future replacement into a contained change rather than a sweep across every resource.

Support. GitHub issues only, no SLA, one primary maintainer, small user base. Acceptable for an admin-panel convenience; not acceptable as a single point of failure for a business-critical authoring workflow without a fork-or-vendor contingency. If adoption grows past a handful of resources, mirror the repository under the org and treat it as internal code.

Scaling. Runtime cost is negligible — this is form rendering, not request-path logic. The practical scaling limit is form weight: N locales × M translatable fields produces wide tabbed forms that slow editors and increase save payloads. Mitigate by translating only fields that genuinely need it and by keeping locale counts deliberate.

Failure modes.

• Locale list drift between package config, spatie config, and app config → blank tabs or, worse, saves that write to unintended keys.
• Missing HasTranslations trait or mismatched column cast → silent overwrite of one locale with another.
• Absent per-locale validation → partially translated records published to users.
• Filament upgrade → field rendering breaks in the admin panel; caught only if a smoke test covers a translatable form.
• Published views → upstream fixes silently ignored.

Ramp-up. A Filament-fluent developer is productive in under an hour; someone new to spatie's translatable conventions needs roughly half a day to internalize JSON-column storage, fallback behavior, and locale-aware validation. The onboarding cost is dominated by our conventions, not the package — which is another argument for documenting the pattern once and standardizing it centrally.