Filament Translation Manager Laravel Package

Technical Evaluation

• Architecture fit: Strong fit for Laravel applications already using spatie/laravel-translation-loader and an admin panel, likely Filament, to manage DB-backed translations. The package wraps language_lines with scan, import/export, quick translate, status tracking, and extension hooks rather than replacing the translation loader.
• Integration feasibility: Feasible for a standard Laravel stack: install via Composer, publish config/migration stubs, apply the binary-key migration stub where needed, define gates, configure groups, and run a dry-run scan before production use.
• Technical risk: Moderate. Main risks are database collation/byte-exact uniqueness on existing language_lines tables, duplicate handling during scan/import, cross-database JSON path queries, cache flush behavior, and scan parser false positives/negatives. The package mitigates several risks with chunked transactions, duplicate skipping, key-length limits, non-destructive prune default, and explicit status columns.
• Key questions: Which Laravel, PHP, Filament, and spatie/laravel-translation-loader versions are supported? Is there a supported migration path from kenepa/translation-manager? What are the production DB engine/collation and existing duplicate conditions? Should scan run in CI, scheduler, or manually? Who owns manageTranslations and deleteTranslations gates? What is the intended prune policy and status workflow?

Integration Approach

• Stack fit: Best suited to Laravel + DB-backed translations + admin UI. The package assumes language_lines, gates, config-driven groups, and optional Filament resource hooks. It is less suitable where translations must remain file-only or where no admin panel exists.
• Migration path: Back up language_lines; install and publish config/migrations; apply make_language_lines_keys_binary for existing MySQL/MariaDB tables; optionally apply add_status_columns_to_language_lines_table; run translation-manager:scan --dry-run; review duplicates, skipped keys, and orphan candidates; then enable production scan with prune.mode=mark.
• Compatibility: Explicit DB support is indicated for MySQL, MariaDB, PostgreSQL, and SQLite JSON paths. Binary key handling is MySQL/MariaDB-specific. Kenepa config keys are accepted, which may ease migration, but version compatibility with Laravel/Filament/spatie must be verified before rollout.
• Sequencing: Configure table, groups, scan.max_key_length, import.max_size, and status/prune settings first. Define gates. Run dry-run scan in staging. Validate import/export, quick translate, search, and language switcher behavior. Enable status tracking and orphan marking. Defer destructive prune.mode=delete until orphan review is trusted.

Operational Impact

• Maintenance: Adds a managed DB table, migration stubs, config surface, scheduled or manual scans, and cache-flush behavior. Status columns are optional but add schema and UI maintenance. Package upgrades will need compatibility checks against Laravel, Filament, and spatie releases.
• Support: Gates are closed unless defined, so access control must be configured deliberately. Translators need guidance on confirmed/orphaned status, cleared locales stored as null, and quick translate/import workflows. Ops needs a scan/prune runbook and DBA review for the binary-key migration on existing tables.
• Scaling: Chunk size 200 with per-chunk transactions and once-per-group cache flush is reasonable for moderate translation tables. Large scans, many groups, or large imports can still pressure DB and cache; groups, scan.max_key_length, and import.max_size are useful controls. Model events still fire per row, so observers should be checked.
• Failure modes: Duplicate unique keys are skipped and counted rather than fatal; collation mismatch can still reject writes; over-length keys are skipped without orphaning rows; cleared locales are not refilled by scan; orphan marking is non-destructive by default, while delete is destructive; oversized imports are blocked; cache staleness is possible if flush fails; locale switcher depends on persistent auth middleware placement.
• Ramp-up: Low-to-moderate for Laravel teams, mostly around migration stubs, gates, and scan/prune semantics. Translator onboarding is straightforward but should cover status badges, “Missing in” filters, and confirmation actions. Initial release reduces upgrade-breakage risk but increases greenfield configuration risk.