Filament Translatable Strings Laravel Package

Getting Started

wotzebra/filament-translatable-strings gives a Filament panel a UI for editing translation strings that live in the database, rather than hand-editing lang/*.php. The core flow is: scan your existing lang files into a translatable_strings table, then let editors manage every locale side-by-side from the admin panel.

v3.0.0 is a major bump. It upgrades to wotz/filament-translatable-tabs v3 and maatwebsite/excel v4, which in practice means Filament 4 and a newer Laravel/PHP floor. Do not attempt to install this on a Filament 3 panel — Composer will resolve you back to v2.x. Check the composer.json constraints before upgrading an existing project.

Minimal setup:

composer require wotzebra/filament-translatable-strings:^3.0
php artisan vendor:publish --tag="filament-translatable-strings-config"
php artisan vendor:publish --tag="filament-translatable-strings-migrations"
php artisan migrate

Register the plugin on the panel that should host the editor:

use Wotzebra\FilamentTranslatableStrings\FilamentTranslatableStringsPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(FilamentTranslatableStringsPlugin::make());
}

Then look first at:

1. config/filament-translatable-strings.php — locale list, table names, scanning paths, import/export toggles.
2. The published migration — confirm the table name matches what you expect before running it against production.
3. The plugin class — it exposes the navigation group/label/icon and the resource registration you'll want to customise.

First use case: run the scan command to populate the table from your existing lang/ directory, open the Filament page, and edit a string in a non-default locale to verify the DB-backed loader is actually being used (clear the translation cache and reload the front end — if the old string still appears, see Gotchas).

Implementation Patterns

DB as the source of truth, files as seed data. The most common deployment shape is: scan lang files once into the database, then let the DB drive runtime translations and treat the files as legacy/seed only. Keep the scan command in your deploy pipeline behind a flag so it doesn't re-import stale strings over editor changes.

Import/export as the review workflow. With maatwebsite/excel v4 in play, the useful pattern is a scheduled or CI-driven export of the strings table to a spreadsheet committed to the repo. Reviewers diff the spreadsheet rather than the database, and translators work in Excel/Sheets without needing panel access. If you need custom column mapping, extend or bind the package's import/export classes rather than post-processing the file — v4's API differs from v3, so any custom WithHeadingRow/ToModel implementations you carry over need re-checking.

Locale tabs via filament-translatable-tabs v3. The tabs component renders one tab per configured locale. Keep the locale array in the config file (not hardcoded in the panel) so it stays the single source for both the editor UI and the export column order. If you support tenant-specific locales, resolve them in a service provider and merge before the panel boots.

Per-panel scoping. In multi-panel apps (admin + a customer-facing panel), register the plugin only where translation editing belongs, and point it at a dedicated navigation group. Don't let a tenant panel expose the full string table.

Permissions. Gate the resource behind a policy or canAccess() closure tied to a dedicated permission (manage translations) rather than the generic admin role — translation editing is a content operation, not an infrastructure one.

Testing. In feature tests, swap the DB-backed loader back to the file loader (or seed the strings table in a factory) so assertions against __() remain deterministic. Without this, tests will pass or fail depending on what's in the translations table.

Gotchas and Tips

The upgrade itself is the main gotcha. v3.0.0 is a hard break: Filament 3 projects cannot mix in filament-translatable-tabs v3, and maatwebsite/excel v4 is a major with its own API changes. Upgrade path: bump the package, re-publish and diff the config and migration files (vendor:publish --force into a scratch dir first — never blindly overwrite), re-run migrations, then clear caches. If you subclassed any of the package's import/export classes, audit them against the Excel v4 API.

Cached translations mask everything. If edits in the panel don't appear on the front end, it's almost always the translation cache or an OPcache/file-loader mismatch, not a save failure. Clear the cache after verifying the row actually changed in the database; that tells you whether the problem is write-side or read-side.

Scanning is destructive by default. Most implementations of this pattern overwrite existing keys on re-scan. Check the config for the overwrite/skip behaviour before running it in production after go-live, or you'll silently revert editor work.

Publishing tags drift between majors. Confirm the actual publish tags from the package's service provider (php artisan vendor:publish with no arguments lists them) rather than copying commands from older docs — v3 renamed things alongside the dependency bump.

Table and column names are configurable but not auto-migrated. If you change the table name in config after the initial migration, the package will query a table that doesn't exist. Change it before first migrate, or write a follow-up migration.

Extension points worth knowing: custom import/export classes (bind your own implementations), the locale resolver in config, navigation registration in the plugin class, and the resource's form/table schemas if you need extra columns (context, description, screenshot). Prefer extending the resource over forking the package — the v3 → v4 Filament transition will hit again.

Watch the vendor directory. Restrict the scan paths to lang/ and your own app code; scanning vendor/ will pull in thousands of package translation keys and bloat the table (and any export you generate).