iabduul7/filament-auto-transliterate
A Filament plugin for automatic transliteration of text fields. Convert input into Latin script or your chosen target as users type, ideal for slugs, multilingual forms, and cleaner data entry. Simple configuration and seamless integration with Filament forms.
Architecture fit. The package ships as a proper Filament plugin (FilamentAutoTransliteratePlugin::make() registered on the panel), which is the expected extension seam for Filament v4/v5. Core behavior is surfaced through a fluent macro (->translatable(), aliased as ->autoTransliterate()) applied to any text input or textarea, so it composes with existing form schemas rather than replacing them. The provider chain is pluggable and configurable per mode, and the two modes are deliberately separated so transliteration cannot silently degrade into meaning-based translation — an important correctness property for a feature users will trust for script output. Server-side translation is fronted by an auth-gated, throttled HTTP endpoint rather than called directly from the browser, which is the right trust boundary: it keeps provider credentials off the client and limits abuse.
Integration feasibility. Install is a three-step, low-ceremony path: Composer require, filament-auto-transliterate:install, php artisan filament:assets. The install command implies it handles config publishing and cache table creation, which reduces manual migration work. The filament:assets step means there is a published JS/CSS asset dependency to keep in the build pipeline. Constraints are explicit and match a modern stack: Filament v4/v5, Laravel 11/12, PHP 8.2+. A team already on that matrix should be able to wire this into a single form in under a day.
Technical risk. The dominant risk is maturity: this is v0.1.0. Pre-1.0 semantic versioning means breaking changes to the macro API, config keys, or provider interfaces are acceptable on any minor bump, and the install command may evolve its schema. Second is third-party dependency risk — the provider chain leans on Google Input Tools, MyMemory, LibreTranslate, Microsoft, and Google, all of which are external services with their own availability, quota, and terms-of-service profiles. Third is data-handling: form input (potentially PII or business content) is sent to third-party providers unless a local dictionary is used, so this needs a privacy review before production use in any regulated context. Fourth is the cross-database cache — "permanent" retention plus a hash index is sensible for correctness, but it means unbounded table growth without a pruning story.
Key questions.
Stack fit. This fits cleanly into a Laravel 11/12 + Filament v4/v5 admin panel — the most common modern PHP admin stack. No framework modification is required; it installs as a Composer package and a panel plugin. Teams on Laravel 10 or PHP 8.1 are excluded and would need to upgrade first, which is the main gating factor.
Migration path. Because the feature is opt-in per field via a macro, adoption is incremental rather than a cut-over. The only irreversible-looking step is the install command's schema changes (cache table); everything else is additive. Start in a single non-critical panel, confirm asset publishing works in your build/deploy pipeline, then expand field coverage. Rollback should be a matter of removing the macro calls and the plugin registration, with the cache table dropped separately.
Compatibility. The declared matrix (Filament v4 and v5, Laravel 11/12, PHP 8.2+) is broad enough that a single package version can serve teams mid-upgrade from Filament v4 to v5 — worth confirming in staging that the macro behaves identically on both. Cross-database cache support matters if the estate runs mixed MySQL/PostgreSQL/SQLite (e.g. prod on Postgres, CI on SQLite); verify the hash-indexed cache works on every engine you actually run, not just the primary one.
Sequencing.
Maintenance. This is a small, single-maintainer-style package at v0.1.0 on a feature that is not core to the business, so the maintenance burden is genuinely low — but so is the maintenance guarantee. Expect to pin a version in composer.json and treat upgrades as reviewed changes rather than routine composer update traffic. Budget for occasional adaptation when Filament ships a minor that touches form field internals, since macro-based extension is closer to the framework's surface than a first-party API.
Support. Internal support load will be modest and mostly in two buckets: "the toggle is on but nothing happens" (provider misconfiguration, throttle, or endpoint auth) and "the output is wrong" (transliteration vs. translation mode confusion, provider quality). The deliberate mode separation helps here — it gives support a clear first diagnostic question. The persistent enabled indicator and in-field spinner are also good support affordances because they make state visible to the user. Document the provider order and default mode for your environment, since that is what most tickets will trace back to.
Scaling. Three scaling dimensions. First, request volume: every space keystroke that triggers transliteration becomes a server-side call unless cached, so the permanent hash-indexed cache is doing real work — confirm hit rates in staging with realistic typing patterns. Second, provider quotas: external providers enforce rate limits and may bill per character, so the throttle defaults and the provider chain's failover behavior directly determine both cost and user experience at scale. Third, cache growth: a permanent, per-input cache on a high-traffic panel will grow monotonically; this needs a retention decision and a purge job, even if the package does not ship one.
Failure modes. Degradation is graceful by design — the field remains a normal text input, so a provider outage means users type Roman Urdu and get no script conversion, not a broken form. Watch for these specific failure paths: provider timeout causing per-keystroke latency spikes (spinner spins, typing feels laggy); throttle saturation under concurrent editors, silently disabling the feature for the remainder of the window; endpoint auth failure after session expiry, which may surface as an unresponsive toggle; and asset publish drift after a deploy, where the JS is stale relative to the endpoint contract. None are data-loss scenarios, but all are visible quality regressions that generate tickets.
Ramp-up. Developer ramp-up is close to zero — one plugin registration, one macro call, one config file. The real ramp-up is on the user and content side: authors need to understand that transliteration produces Urdu script from Roman Urdu phonetics without changing meaning, and that translation is a separate opt-in mode. That distinction is the single most important thing to communicate in onboarding, because users who expect meaning-level translation from the default mode will report the feature as inaccurate. A short internal note covering mode semantics, the header toggle, and the local-dictionary fallback should be sufficient.
How can I help you explore Laravel packages today?