Weave Code
Filament Translatable Field Laravel Package
34ml/filament-translatable-field
A Filament form field for editing translatable model attributes across multiple locales. Add locale-aware inputs to Laravel Filament resources to manage translations alongside other fields, with configurable locales and support for Spatie Laravel Translatable in a clean, native UI.
Filament translatable field
Frequently asked questions about Filament Translatable Field
- How do I install 34ml/filament-translatable-field in a Laravel app?
- Install it with Composer using composer require 34ml/filament-translatable-field. Then register the plugin or service provider in your target Filament PanelProvider. Finally, swap or add the translatable field inside your resource form schema and pass in the locales you want to edit. No changes to public routes, APIs, or queues are required because the package only touches admin panel form rendering.
- Which Laravel and Filament versions does this package support?
- The v3.0 release explicitly targets Filament v5 and Laravel 13, which is the forward-looking pairing. The package has effectively zero value if your panel is still on Filament v3 or v4, so plan the upgrade alongside a framework upgrade rather than independently. Build and record an explicit compatibility matrix of Laravel, Filament, PHP, and translation backend versions before committing. Any combination you still run in production should be verified green first.
- Does filament-translatable-field require spatie/laravel-translatable?
- The field is designed to sit on top of an existing translation-storage convention, and in practice that is usually spatie/laravel-translatable. It is primarily a form component for rendering and writing locale-aware inputs, not a translation backend of its own. Confirm which backend major version is supported before adopting, since the README does not document a full compatibility matrix.
- How do I configure which locales appear in the translatable field?
- Locales are configurable, so you define the set of locale codes you want editors to fill in and pass them to the field in your form schema or package config. Each locale gets its own input, letting editors manage translations alongside the rest of the resource fields in a native Filament UI. Keep the locale list aligned with your app's configured locales to avoid key mismatches on save.
- Can I add a translatable field to an existing Filament resource form?
- Yes. Because it is a leaf form-field component, adoption is usually as simple as replacing or adding the field in your resource's form schema and importing the class. The write path for translated attributes is the only thing affected, so other fields, tables, and actions stay untouched. After swapping, diff the rendered output and saved values across every configured locale before merging.
- What are the breaking changes in version 3.0 of this package?
- The 2.x to 3.x bump is a semver-major signal, but the published release notes are thin and list only a couple of pull requests with no dedicated breaking-change or migration section. Plausible breaks for a field component include namespace or class moves, renamed field-builder methods, changed state casting for locale arrays, and asset or view registration changes. Treat these as unverified and validate each one against your panel before upgrading.
- How should I test that translations are saved correctly for every locale?
- Write feature tests that fill each locale input through Filament's Livewire form testing helpers and then assert the persisted translated attribute per locale. Add a case that edits one locale while others hold values, to catch a null-overwrite bug. The realistic worst failure here is silent translation loss on save rather than an exception, so assert the full JSON payload rather than a single field. Document a manual QA script as a backup if the package's own CI coverage is unclear.
- Is filament-translatable-field safe to use in production?
- The blast radius is limited because the package only affects admin panel editorial forms and not public rendering, APIs, or background jobs. The real risk is data integrity: a locale key mismatch or null-overwrite can silently drop translations without throwing an error. Maintenance risk is also a factor, since the package is maintained by a single agency with a small contributor base. Pin the version, test the persistence path, and keep a local fork as a contingency.
- What should I do if our panel still runs Filament v3 or v4?
- Stay on the 2.x line and confirm the field's behavior is covered by a test or a documented manual QA script. Do not upgrade this package independently of the framework, because the two releases are coupled. The recommended order is to pin 2.x, upgrade Filament to v5 on a branch, upgrade the package to 3.0, then diff rendered output and persistence across all locales. If 3.0 proves unstable, vendoring a small pinned copy is a credible fallback.
- What are good alternatives to this Filament translatable field package?
- You can build the same thing with core Filament components using tabs or a repeater bound to your translation array, which avoids an extra dependency entirely. Other community Filament translation-field packages exist, and some teams simply wrap spatie/laravel-translatable in a custom field. Given the small surface area here, a short in-house implementation or fork is a realistic alternative if maintenance cadence becomes a concern.
Weaver
How can I help you explore Laravel packages today?