Ar Php Laravel Laravel Package

Product Decisions This Supports

• MENA/Arabic localization roadmap. This package is a thin Laravel integration over the Ar-PHP Arabic language library. It underpins decisions like "ship an Arabic-first experience this quarter" without committing engineering to building an in-house Arabic text-processing layer.
• Search and content quality. Arabic text normalization (diacritic/harakat stripping, tatweel removal, alef/ya/ta-marbuta unification) directly determines whether search, deduplication, and matching work for Arabic content. This is a build-vs-buy call this package lets you answer cheaply.
• Calendar and date features. Hijri/Gregorian conversion supports date pickers, holiday logic, statements, invoices, booking flows, and marketing calendars for Gulf and broader Arabic-speaking markets.
• Presentation and formatting. Arabic-Indic numerals, currency/number formatting, and transliteration (for URL slugs, export filenames, and legacy-system keys) are all user-visible polish items that typically land in a localization epic.
• Prioritization signal for 3.0.0. This release is a compatibility and maintenance release, not a feature release: CI/dependency bumps plus added Laravel 13 support on PHP ^8.2. It does not unlock new product capability, but it does extend the supported-platform window, which matters if your roadmap includes a Laravel upgrade. Treat it as a keep-the-lights-on item rather than a feature input.

When to Consider This Package

Adopt when:

• You have shipped, or are about to ship, Arabic-language content and need normalization, Hijri dates, Arabic numerals, or transliteration in a Laravel codebase.
• You are standardizing on Laravel 13 with PHP 8.2+ — 3.0.0 explicitly targets that combination, so greenfield and upgrade work can adopt it cleanly.
• You want the Arabic-processing behavior encapsulated behind a service provider/facade rather than scattered through application code.
• Your needs are deterministic, rule-based Arabic text handling — not statistical or model-driven NLP.

Look elsewhere / defer when:

• No Arabic-facing users on the roadmap; the dependency is pure carrying cost.
• You need deeper linguistic capability (morphology, stemming beyond basic normalization, dialect handling, ML-based classification). Ar-PHP is a rules-and-utilities library, not an NLP platform.
• You need a vendor with commercial support, SLAs, or a large maintained contributor base — this is a small, single-maintainer-style wrapper around an upstream library, so upstream health and release cadence are part of your risk.
• You are on an older Laravel/PHP line. Version 3.0.0 is a major bump and the notes only describe adding Laravel 13 support; they do not state which Laravel or PHP versions were dropped. Confirm the composer constraint matrix before planning an upgrade — a major version is a reasonable signal that older framework support was removed.
• Native intl/ICU already covers your narrow need (e.g. simple number or date formatting) and Arabic-specific text handling is not required.

How to Pitch It (Stakeholders)

For executives: We can support Arabic-language customers — correct search behavior, Hijri dates, Arabic number formatting, and readable URLs — by adopting a small, focused Laravel package instead of funding custom R&D. Cost is one Composer dependency and minimal integration effort. The new 3.0.0 release is a maintenance release: it keeps us current with the newest Laravel version and modernizes the project's build tooling. There is no new feature to market, but it removes a blocker if our platform upgrade is on the roadmap.

For engineering: It's a Laravel service-provider/facade wrapper over the established Ar-PHP library — you get Arabic text normalization, Hijri conversion, numeral formatting, and transliteration behind a familiar container-bound API rather than hand-rolled regexes. 3.0.0 adds Laravel 13 support and requires PHP ^8.2; the remainder of the changelog is Dependabot/CI hygiene. Because it is a major version, verify the package's Laravel/PHP constraints against our matrix before upgrading, and pin the version. Risk is concentrated upstream: audit Ar-PHP's maintenance status and pin both packages; wrap calls behind our own adapter so a future swap is a one-file change. Recommended sequencing: spike the upgrade in a branch, confirm the supported-version matrix, then roll it in with the Laravel upgrade rather than as a standalone change.