Product Decisions This Supports
- Localization roadmap prioritization. If a meaningful slice of your admin users are Persian-speaking, this package is a cheap test of whether Jalali-date filtering actually drives admin engagement before you commit engineering time to a broader RTL/calendar localization program.
- Build vs. buy for a narrow feature. The feature itself (a date-range filter rendered in Jalali/Shamsi instead of Gregorian) is small. This package frames the “buy” option honestly: a 6-star, single-purpose dependency versus roughly a day of in-house work wrapping an established Jalali conversion library.
- Admin UX decisions. Forces an explicit call on whether Nova’s default Gregorian filter is acceptable for your ops/support teams, or whether date entry in the Persian calendar is a genuine workflow requirement (e.g., finance periods, campaign scheduling, subscription cycles aligned to Iranian months).
- Technical-debt budgeting. Last release February 2020 with zero dependents is a signal, not a footnote. It informs whether you adopt as-is, vendor a fork, or treat it purely as a reference implementation for your own filter class.
- Use cases it serves: internal admin panels and back-office tooling on Laravel Nova where operators think in Jalali dates — reporting windows, order/booking history, content scheduling — rather than customer-facing product surfaces.
- Not a product differentiator. Nothing here touches end-user experience or revenue directly; frame it as internal tooling efficiency, not a roadmap feature.
When to Consider This Package
Consider it when all of the following hold:
- You are already running Laravel Nova — this package is meaningless without it, and Nova is a paid, licensed dependency, so the addressable audience is inherently small.
- Your admin/ops users are Persian-speaking and have explicitly asked for Jalali date filtering, or you are seeing date-entry errors from Gregorian-only filters.
- Your Nova version is contemporary with the package’s 2020 release (Nova 2.x/3.x era). Verify compatibility before any adoption decision — this is the single biggest unknown.
- You are comfortable treating it as source material: fork it, pin it, or copy the filter logic into your own
app/Nova/Filters directory.
Look elsewhere — or build in-house — when:
- You are on Nova 4/5, or plan to upgrade. An unmaintained 2020 package is a blocker on that path, not a detour.
- Your organization requires maintained dependencies, security review, or vendor support. Six stars, zero dependents, and no release in five years will fail most dependency policies.
- You need Jalali support beyond a filter — validation, casts, model attributes, exports, date pickers. Pair a maintained conversion library (e.g., a Jalali/Verta-style package) with a custom Nova filter instead.
- You are not on Nova at all. Do not adopt Nova as a side effect of wanting Persian dates.
How to Pitch It (Stakeholders)
For executives: This is a small, free, open-source add-on that lets our internal admin panel display and filter dates in the Persian calendar. It’s a low-cost way to test whether calendar localization improves our back-office team’s efficiency before we invest in a wider localization effort. The caveat is maintenance: the package hasn’t been updated since 2020, so I’d budget a small amount of engineering time to fork and own it rather than depend on the original author. Total cost of a trial is measured in days, not weeks — and it’s fully reversible.
For engineering: Single-purpose Nova filter, ~2020 vintage, likely Nova 2/3 compatible only. Recommendation is to spike it against our Nova version first; if it works, vendor a fork into our repo and pin it. If it doesn’t, the fallback is a one-day custom filter wrapping a maintained Jalali conversion library — same UX, no abandoned dependency. Either way, do not introduce it as an unpinned Composer requirement, and do not let it block a future Nova upgrade.
Bottom line: Worth a time-boxed spike if Persian admin UX is a real pain point and we’re on an older Nova. Not worth it as a long-term dependency, and not worth discussing if we’re not on Nova.