Laravel Arabic Numbers Middleware Laravel Package

Technical Evaluation

• TPM recommendation: Conditional pilot only. Treat this as a small input-normalization utility, not a strategic i18n dependency. Use it route-scoped behind a config flag, with tests and a fork/vendor fallback. The low adoption signal (19 stars, score 0.525) and no release since January 2023 make it unsuitable as an unexamined global middleware dependency.
• Architecture fit: Narrow Laravel HTTP middleware that converts Arabic-Indic/Eastern Arabic digits such as ١٢٣٤٥٦٧٨ to ASCII digits 12345678. Good fit where users type Arabic digits but validation, storage, search, and downstream APIs expect ASCII. Poor fit as a complete localization layer; output formatting and display localization remain separate concerns.
• Integration feasibility: Technically simple: Composer install, register middleware, choose global vs route-group scope. Feasibility depends on verifying actual input coverage: form body, JSON payloads, nested arrays, query strings, route parameters, headers, and file metadata. Also verify middleware ordering relative to validation, authentication, signed URLs, TrimStrings, and ConvertEmptyStringsToNull.
• Technical risk: Code risk is likely low; maintenance and coverage risk are medium. Risks include stale Laravel/PHP compatibility, single-maintainer abandonment, incomplete handling of Persian/Urdu digit ranges, Arabic decimal/thousands separators, mixed text, leading zeros, and over-normalization of free-text fields where Arabic numerals are content rather than data. Canonicalization must happen before validation consistently across web and API paths, or validation behavior will diverge.
• Key questions: Which Laravel and PHP versions are supported by composer.json? Which digit ranges and separators are converted? Is conversion configurable by field/route, or all-or-nothing? Does it mutate JSON, query, route, and nested inputs? Is it idempotent for already-ASCII input? Are there tests? Who maintains it, and what is the response SLA? Can the team vendor/fork it under MIT? How are signed requests, encrypted payloads, audit logs, and original user input preserved?

Integration Approach

• Stack fit: Fits standard Laravel HTTP kernel middleware. Start as route middleware on selected public Arabic-input endpoints, not as global middleware. Pair with Form Requests/validation and keep output localization in views or API resources.
• Migration path: Run a bounded pilot on one low-risk form or API endpoint. Add a feature flag, capture before/after input samples, and write contract tests for Arabic-Indic digits, Eastern Arabic-Indic digits, mixed strings, leading zeros, phone numbers, IDs, and financial values. If coverage is insufficient, vendor the code or replace it with a small custom middleware.
• Compatibility: Confirm a CI matrix against the organization’s supported PHP and Laravel versions. Test middleware priority explicitly: conversion must occur after request initialization and before validation/authorization logic that depends on canonical digits. For APIs, verify JSON body handling; for web forms, verify Form Request behavior. If the package lags current Laravel, apply a Composer patch or fork rather than forcing an outdated framework.
• Sequencing: 1) inventory endpoints and fields that accept Arabic digits; 2) define policy: ASCII canonical storage, localized Arabic display; 3) install and register route-scoped behind config; 4) add automated tests and middleware-order tests; 5) verify auth, signed URL, and audit behavior; 6) monitor validation failures and support tickets; 7) expand scope only after pilot acceptance.

Operational Impact

• Maintenance: Low ongoing code maintenance but elevated stewardship risk due to age and low adoption. Assign an owner, review annually, and track Laravel upgrades. MIT licensing lowers IP risk and permits vendoring, which should be the fallback plan.
• Support: No vendor SLA and a very small community. Internal runbooks, tests, and a named maintainer are required. If a defect appears, expect to fix it in a fork rather than wait for upstream.
• Scaling: Runtime cost should be negligible for small payloads, but global middleware on high-traffic APIs can add measurable CPU if it walks large JSON trees or applies regex broadly. Benchmark representative payloads and prefer field-scoped normalization if possible.
• Failure modes: Over-conversion corrupts free-text content or names; under-conversion causes validation and lookup failures; inconsistent web/API normalization creates data mismatches; wrong middleware order makes conversion ineffective or breaks signed requests; missed nested JSON or query inputs produce partial behavior; Arabic decimal separators and leading zeros can corrupt numeric interpretation; audit logs may lose the user’s original input. Provide a kill switch via config.
• Ramp-up: Engineering ramp-up is low: one middleware registration plus tests. Product and QA need a short Arabic-digit test matrix, and support needs guidance on canonical storage versus localized display. A pilot can likely be assessed in engineering days, but production hardening and ownership should be budgeted before broader rollout.