Arabify Laravel Package

Product Decisions This Supports

• MENA localization completeness. Whether numerals render as Arabic-Indic (٠١٢٣), Eastern Arabic/Persian variants, or Western digits in prices, invoices, receipts, dashboards, and PDF exports — a visible detail that users in Gulf/Egypt/Levant markets read as a signal of whether the product was actually built for them.
• Build vs. buy for formatting logic. The alternative is hand-rolling numeral conversion plus intl/NumberFormatter plumbing, or embedding a third-party helper. A small, focused package is the cheaper bet for a single formatting concern, provided the upgrade path is safe.
• Display-layer scope decision. This is presentation, not business logic. It supports a roadmap choice to localize rendering now (low risk, high visibility) while deferring deeper i18n work like translated content, pluralization, and localized date/calendar systems.
• Market sequencing. Cheap to pilot on one locale or one surface (checkout, invoices) before committing to a full Arabic-first release; results inform whether to invest further in the Arabic UX track.
• Release v1.3.2 ("Modify Where The Arabify Function Should Place") changes where the helper is placed — a structural/autoload-level change, not a formatting fix. A patch-version bump that moves code is a classic silent-upgrade-breaker (helper file path, composer.json files autoload, service-provider registration, namespace). For a PM this is a vendor-maintenance risk signal, not a feature: it should trigger a "pin the version, verify our call sites, read the diff" action before any upgrade, and it argues for wrapping the helper behind one internal adapter rather than calling arabify() scattered across views.

When to Consider This Package

Adopt when:

• You ship a Laravel app to Arabic-reading markets and numerals are currently inconsistent or wrong on customer-facing surfaces.
• You want a narrow, replaceable dependency for one concern rather than a full i18n framework.
• You can pin the version and own the upgrade review — the maintainer's release hygiene looks informal (vague, single-line notes, structural changes in a patch release).

Look elsewhere or hold when:

• You need more than numeral formatting — date/calendar localization, pluralization, translated copy, RTL layout. This package will not carry that; reach for Laravel's translation layer plus intl.
• You have compliance- or finance-grade output (regulatory invoices, tax documents) where a formatting library with a formal changelog and semantic-versioning discipline is required.
• Your team cannot inspect the diff for v1.3.2 — treat unknown structural changes as a blocker, not a nice-to-have.
• Non-Laravel or non-PHP services are in play; the value is in the framework integration.

How to Pitch It (Stakeholders)

To executives: A small, low-cost Laravel add-on that makes numbers display correctly for Arabic-speaking customers — a visible quality signal in the markets we're prioritizing, shippable in days rather than as a localization program. It is a display-layer improvement, not a commitment to full Arabic localization.

To engineering: A focused helper for Arabic numeral rendering that removes bespoke formatting code. Two caveats: keep it behind a single internal adapter so we can swap it out, and do not auto-upgrade — v1.3.2 relocates the helper function, which can break autoloading and existing call sites. Pin the current version, review that diff, and verify the helper path and service-provider registration before bumping.