Filament Auto Transliterate Laravel Package

Product Decisions This Supports

• Localization strategy for Urdu-speaking markets: enables a decision to ship Urdu-first data entry surfaces (forms, admin panels) without committing to a full translation management system or separate Urdu-language UI. Useful when the roadmap includes Pakistan, diaspora, or South Asian user bases.
• Build vs. buy for input localization: replaces an in-house transliteration microservice (dictionary maintenance, provider fallback logic, caching, rate limiting) with an off-the-shelf plugin — a clear "buy" signal for anything short of a differentiated language feature.
• Feature scoping for internal ops tooling: lets PMs greenlight operator/admin workflows where staff think in Roman Urdu but records must be stored in Urdu script (KYC forms, CRM notes, catalogue entry) without retraining or dual-system data entry.
• Risk posture on translation vs. transliteration: the strict separation of transliterate (script conversion) and translate (meaning) modes is a product-safety decision — it prevents meaning drift from silently corrupting names, addresses, and identifiers. This supports a default-off stance on translation.
• Vendor/architecture decisions: Filament v4/v5 and Laravel 11/12 support means this fits the current admin-stack roadmap without a version freeze; the pluggable provider chain keeps optionality open (swap Google for self-hosted LibreTranslate for data-residency reasons).
• Metrics to instrument: typing-to-Urdu adoption rate, endpoint latency, cache hit ratio, and rate-limit rejections — all observable and tied to the throttled endpoint plus hash-indexed cache.

When to Consider This Package

Consider adoption when:

• The admin/staff surface is Filament-based and forms are the primary data-entry channel — the ->translatable() / ->autoTransliterate() macro value is concentrated in Form Builder inputs and textareas.
• Your users type Roman Urdu but need Urdu script stored, and you want that to happen in-field rather than via a post-submit batch job or a separate translation queue.
• You need both script conversion and optional meaning translation but cannot tolerate the two being silently conflated.
• You want provider redundancy — the chain (Google Input Tools, MyMemory, LibreTranslate, Microsoft, Google, local dictionary) suits products that need a self-hosted/offline fallback or must avoid a single external dependency.
• You need a permanent, cross-database cache and a one-command installer, and you're comfortable with an auth-gated, throttled internal HTTP endpoint.

Look elsewhere when:

• The product is not on Filament — the value is entirely in the Filament form layer; a standalone Laravel app gains little.
• You need production-grade SLA guarantees — this is a v0.1.0 initial release with a single maintainer namespace; treat it as early-adopter risk.
• Strict data residency rules forbid third-party text APIs and you cannot stand up the local dictionary or LibreTranslate path.
• You require languages beyond Urdu/Roman Urdu — scope is explicitly narrow.
• You need multi-tenant cache isolation or per-user provider policy — not described in this release; verify before assuming.
• Your stack is Laravel 10 or PHP < 8.2 — hard floor at Laravel 11/12 and PHP 8.2+.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost plugin that removes a genuine friction point for Urdu-speaking staff — they type naturally in Roman Urdu and the field stores proper Urdu script. It converts what would otherwise be a translation vendor contract or a bespoke integration project into a two-command install. The strategic value is market readiness: it lets us open Urdu-language admin workflows without building a localization program. Main caveat: this is a brand-new v0.1.0 release, so we should pilot it on one internal form before any customer-facing commitment.

For engineering: The plugin adds a ->translatable() (alias ->autoTransliterate()) macro to Filament text inputs and textareas, backed by an auth-gated, throttled HTTP endpoint and a permanent, hash-indexed, cross-database cache. Provider resolution is pluggable and configurable per mode, with transliterate as the hard default and translate as explicit opt-in — the separation is enforced, not conventional, which is the property we care about most. It targets Filament v4/v5, Laravel 11/12, PHP 8.2+, installs via filament-auto-transliterate:install, and requires php artisan filament:assets plus plugin registration.

Recommended next step: timebox a spike on a single non-critical admin form; measure endpoint latency and cache hit rate, confirm which providers we're permitted to call, and reassess the version/maturity risk before broader rollout.

Decision framing: adopt for internal ops tooling now (low blast radius, high workflow gain); defer customer-facing adoption until the package has a release history and we've validated provider choice against our data-handling policy.