Filament Translatable Field Laravel Package

Technical Evaluation

Architecture fit 34ML/Filament-Translatable-Field is a narrow, single-purpose Filament form-field plugin — it adds a translatable input component to Filament form schemas, layered over an existing translation-storage convention (typically spatie/laravel-translatable). Architecturally this is a leaf dependency: it touches only admin-panel form rendering and the write path for translated attributes. It does not sit in request/response hot paths, queues, or public APIs, so architectural coupling is low and reversible.

Integration feasibility Integration is conventional for the Filament ecosystem: Composer require, register the plugin/service provider in the target PanelProvider, then swap or add the field in resource form schemas. The v3.0 release explicitly targets Filament v5 and Laravel 13, which is the correct forward-looking pairing — but it also implies the package's supported matrix has moved. Feasibility is high if our panel is on (or moving to) Filament v5; it is effectively zero-value if we remain on Filament v3/v4.

Technical risk

• Thin release notes on a major bump. A 2.x → 3.x bump is a semver-major signal, yet the notes list only two PRs and no breaking-change or migration section. For a field component, plausible breaks include namespace/class moves, changed field-builder method names, altered state-casting for locale arrays, and asset/view registration changes. Unverified.
• Dual dependency on two fast-moving upstreams. Value is entirely contingent on Filament and Laravel release cadence. Every Filament major forces a coordinated plugin upgrade; we inherit that churn.
• Vendor concentration. Maintained by a single agency (34ML) with a small contributor base. Bus factor and long-term maintenance continuity are unproven.
• Data-integrity surface. The worst realistic failure is silent translation loss on save (locale key mismatch, null-overwrite of non-active locales), which is a content problem, not a crash — easy to miss in QA.
• Unknowns in the source data. No composer.json, test matrix, CI status, download counts, or issue-triage data was available for this review.

Key questions

1. Does v3.0 drop Filament v3/v4 and Laravel ≤12, or support both? Is v2.x still receiving security/bug fixes, and for how long?
2. What is the exact compatibility matrix — PHP floor, Filament v5 minor, spatie/laravel-translatable major?
3. Are there breaking API changes beyond dependency bumps, and is there a written upgrade guide?
4. Is there CI coverage across the matrix, and are there tests asserting translated-attribute persistence (the data-loss path)?
5. Does the package impose a storage convention, or is it agnostic to the translation backend?
6. What is the release cadence and issue-response history over the last 12 months?

Integration Approach

Stack fit Assumes Laravel + Filament admin panel. The package is admin-only: it does not affect public site rendering, APIs, or background jobs. That containment is the single most useful fact for planning — blast radius of both adoption and regression is limited to editorial workflows.

Migration path

• Prerequisite-gated. Treat v3.0 as blocked until the panel is on Filament v5 / Laravel 13. Do not attempt to upgrade this package independently of the framework upgrade; the two are coupled.
• Ordering: (1) pin current v2.x and confirm the field's behavior is covered by a test or a documented manual QA script; (2) upgrade Filament to v5 on a branch; (3) upgrade this package to v3.0; (4) diff the field's rendered output and persistence behavior across all configured locales.
• Fallback: because the component is small, a local fork or a vendored copy pinned to our Filament version is a credible contingency if v3.0 proves unstable or the maintainer stalls.

Compatibility Build and record an explicit matrix before committing: Laravel 11/12/13 × Filament v4/v5 × PHP version × translation backend version. Any cell we still run must be green. If v3.0 is a hard cut, document the exact date after which we are off the supported path on v2.x.

Sequencing Prototype in a throwaway branch first to surface API breaks cheaply → expand to a full panel build → staging with a seeded multi-locale dataset → production behind the existing framework-upgrade release, not as a standalone deploy. No feature flag is needed for runtime safety, but a data-verification step (spot-check translated records pre/post) should gate promotion.

Operational Impact

Maintenance This dependency imports the maintenance cadence of two upstreams. Budget a recurring upgrade line item per Filament major (roughly annual-to-18-month cadence). Ownership should sit with the team that owns the admin panel, not a shared platform team, since the failure mode is editorial, not infrastructural.

Support No commercial support expected. Upstream is community/agency-maintained GitHub issues. Internally we need a named owner, a pinned version, and a documented "if abandoned" plan — for a component this small, forking is a realistic and cheap exit.

Scaling Negligible runtime cost: rendering is bounded by (form fields × locales). The only scaling concern is form payload and editor UX in panels with many locales and many translatable fields — a usability and request-size issue, not a throughput issue. No impact on application scaling characteristics.

Failure modes

• Silent translation loss on save — highest-severity, lowest-visibility. Mitigate with an automated assertion that all locales persist after a form submission.
• Panel boot failure after upgrade (service provider, view/asset, or class-name changes) — loud, caught immediately, low duration.
• Field renders but state is not hydrated for the active locale — confusing for editors, looks like a content bug.
• Dependency dead-end — v2.x goes unpatched while we wait on our framework upgrade; security exposure is low (admin-only) but nonzero.
• Version skew across panels if multiple Filament panels exist on different framework versions.

Ramp-up Low. A developer already productive in Filament needs a few hours to adopt the field and its locale conventions; the real cost is the framework upgrade it is bundled with, not this package. Editor-facing training is a short note on locale switching behavior.

Recommendation: Adopt v3.0 only as a rider on the Filament v5 / Laravel 13 upgrade, not as an independent change. Approve after the compatibility matrix and a persistence test are in place; keep a vendored-fork fallback documented given the small-vendor risk.