Weave Code
Filament Plugin Translatable Inline Laravel Package
parfaitementweb/filament-plugin-translatable-inline
A Filament addon for LaraZeus Translatable that lets you edit translations directly below each field, making translatable fields easy to spot, speeding up editing, and revealing missing translations at a glance.
Filament Plugin - Translatable Inline is an addon for Filament Larazeus Translatable that lets you edit translations directly below each field instead of switching locales. Wrap any translatable field in a TranslatableContainer and missing translations become immediately visible, making multilingual forms faster to maintain.
- Edit all locale values inline, right under the original field
- Quickly spot missing or incomplete translations
- Optional
onlyMainLocaleRequired()andrequiredLocales()helpers - Works with Filament v4/v5 and requires the LaraZeus Translatable plugin
- Simple setup: just add the
Translatabletrait and wrap your fields
Frequently asked questions about Filament Plugin Translatable Inline
- How do I install parfaitementweb/filament-plugin-translatable-inline?
- Install it with Composer by running composer require parfaitementweb/filament-plugin-translatable-inline:"^4.0". The package is an addon to LaraZeus Spatie Translatable, so you also need lara-zeus/spatie-translatable installed if it is not there already. There is no service provider registration or config publishing step described in the docs; the setup is just those two Composer requirements.
- Which Filament versions does this plugin support?
- It requires the latest version of Filament v4 or v5, so it is not usable on older Filament v3 panels. It also requires the LaraZeus Filament Translatable plugin plus Spatie translatable on your Eloquent models. Check your composer constraints before adding it to a panel that is still pinned to an earlier Filament release.
- Can I use TranslatableContainer alongside Filament's locale switcher or translation traits?
- No. The documentation explicitly warns that adding the Filament translation traits and the header locale-switcher action to the same resource pages will break the plugin. Only the Translatable trait on the resource is required. On resources that already rely on the header locale switcher, adopting this package is a page refactor rather than a drop-in addition.
- How do I make a Filament form field translatable inline?
- Wrap the field in TranslatableContainer::make() inside your form schema, passing the original component as the argument. For example, TranslatableContainer::make(TextInput::make('title')->maxLength(255)->required()). Repeat the wrapping for every field that needs per-locale inputs, and the translation inputs render directly below each one.
- How do I require only the main locale and leave other languages optional?
- Chain onlyMainLocaleRequired() on the TranslatableContainer after the make() call. That keeps the source locale mandatory while the other locale inputs stay optional, which suits content that gets translated after it is first published. It is the usual choice when editors write in one language and translators follow later.
- How do I require translations for specific locales only?
- Use requiredLocales(['en', 'es']) on the container and list the locale codes that must be filled in. Validation applies per locale on the inline inputs rather than to the whole model. Combine it deliberately with onlyMainLocaleRequired() so the rules match your editorial policy for each resource.
- Does this package change how translations are stored or require migrations?
- No. Storage, retrieval and locale resolution stay owned by spatie/laravel-translatable and its Filament bridge, so there is no schema change, no migration and no new translation store. The addon only contributes a presentation-layer form component that renders per-locale inputs beneath the field. Removing the Composer package leaves your existing translation data untouched.
- Do afterStateUpdated closures and live fields still work with inline translations?
- They can, but they need auditing rather than assuming they will keep working. Wrapping a field in TranslatableContainer adds a level of state nesting, so afterStateUpdated closures must be rewritten to reach the locale value, typically with a locale lookup via the component meta. Any auto-slug, derived-field or live-validation logic on the affected resources should be reviewed line by line before release.
- Is this plugin safe for production when it has a single maintainer?
- The risk is supply chain rather than runtime: a small star count, one maintainer and a dependency chain three hops deep sitting under a form your team touches daily. For internal admin tooling that is usually acceptable if you pin the version, read changelog entries before upgrading and keep a fork as a ready fallback. Name an internal owner in case upstream maintenance goes quiet.
- Should I use this plugin or build inline translation fields myself?
- For a small surface area, installing it is normally cheaper than spending one or two weeks hand-rolling stacked locale inputs and missing-translation highlighting. Adoption is per field and per resource, so you can pilot it on one low-traffic resource in a non-production environment before expanding. If a particular resource would require forking the package heavily, building a tailored component becomes the cheaper option.
Weaver
How can I help you explore Laravel packages today?