Laravel Int Laravel Package

Product Decisions This Supports

• Localization / market-expansion roadmap. Any decision to launch in a new country brings a number-convention problem: 1,234.56 in en-US is 1.234,56 in de-DE, and currency symbols, grouping, and decimal precision all shift. This package is a candidate answer to "how much engineering does locale-correct formatting cost us?" — the answer is small, which keeps localization scoped as a series of incremental epics rather than a platform rewrite.
• Build vs. buy for a deliberately unglamorous capability. Formatting and parsing locale-aware numbers is commodity work with a visible failure mode (wrong prices, wrong invoices, wrong dashboards). The PM decision is not "should we be world-class at number formatting" — it is "do we own ~200 lines of ext-intl glue, or depend on someone else's?" That is a buy-side question with a low ceiling, and this package sits at the cheap end of it.
• Checkout, billing, and invoicing features. Currency and percentage rendering is a trust surface. A misformatted total costs more in support tickets and refund handling than the feature costs to build.
• Localized input capture. Accepting user-entered amounts in a European or Brazilian locale requires parsing ("1.234,56" → 1234.56), not just display formatting. This is where homegrown solutions most often break and where a small helper library earns its keep — relevant to admin tooling, CSV imports, and quote/estimate flows.
• Reporting and export surfaces. Per-locale number formatting in generated PDFs, spreadsheets, and emailed statements — usually a second-order requirement that surfaces late and gets underbudgeted.
• Explicit non-decision: this is not an i18n strategy. It does not cover translations, date/time, pluralization, RTL, address formats, or FX conversion. Adopting it should not be read as progress on a localization OKR beyond one narrow slice.

When to Consider This Package

Consider it when:

• You are on a Laravel version predating the native Illuminate\Support\Number helpers (roughly pre-Laravel 10), or you need parsing/formatting behaviors that the native helpers do not expose.
• Your product genuinely needs both directions — display and accept-localized-input — in many locales, and you do not want to hand-roll NumberFormatter configuration and its error-prone locale rules.
• The consuming surface is non-critical: internal dashboards, admin views, secondary reporting. A bug here is cosmetic, not financial.
• You want to see a compact reference implementation of how locale-aware formatting should be wired into a Laravel app, even if you ultimately vendor the idea.

Look elsewhere or build in-house when:

• You are on Laravel 10+/11+. The framework ships number/currency/percentage formatting and, in recent versions, parsing. Adding a dependency to duplicate framework behavior is a net negative on maintenance and security review.
• Community signal matters. This package has effectively none: no stars, zero dependents, sparse metadata. That is not disqualifying for a thin pure-function library, but it means nobody else has validated it in production. Treat it as unaudited code, not as an ecosystem standard. Anything on a revenue-critical path needs an internal wrapper and tests regardless of which option you pick.
• You need the rest of i18n. Reach for framework-native helpers plus established translation and date libraries; do not let one narrow utility imply broader coverage.
• You need currency conversion or financial-grade precision. Formatting ≠ conversion ≠ decimal arithmetic. Money handling needs a dedicated decimal/money approach, and regulated reporting needs an auditable, owned code path.
• Your organization has dependency-review requirements (license scan, security policy, maintenance SLA). A single-maintainer package with no visible release cadence will fail that gate more often than the code itself warrants.

How to Pitch It (Stakeholders)

To executives (one paragraph): Formatting numbers and currency correctly per locale is a small but high-visibility piece of entering new markets — a wrong decimal separator in a checkout total undermines trust faster than almost any other defect. The engineering cost is measured in days, not weeks, and the blast radius is contained. My recommendation: we get locale-correct formatting into the next release, but we build it on the framework's native number helpers rather than adding an unaudited third-party dependency. We keep this package on the shelf as a reference implementation, not on the critical path. Total ask: roughly two to three engineering days plus QA across our top three locales.

To engineering: Small surface area, thin wrapper over PHP's ext-intl. The technical risk is maintenance and provenance, not correctness — one maintainer, no adoption signal, no visible security posture. If we adopt it, it goes behind an internal formatting interface so we can swap it for framework-native helpers without touching call sites, and we add tests covering our actual target locales. Please confirm whether the native Number helpers cover our parsing needs; if they do, this package is redundant.

Decision requested: Approve locale-correct number/currency formatting as a scoped slice of the localization epic, with a build-on-framework recommendation and this package retained as an evaluated fallback.