Laravel Intl Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. Locale-correct prices, dates, and percentages are a launch blocker for any non-US market. This package collapses that work into a thin facade call, so it changes the cost side of "which market next" conversations — markets that were previously gated on formatting work become cheap.
• Build vs. buy vs. borrow. The real decision is not "buy this" but "wrap NumberFormatter/IntlDateFormatter in our own class, or vendor a 200-line facade?" Because the package is thin, we can adopt it today and replace it internally in a day if maintenance stalls. That makes it a low-consequence decision — treat it as a utility dependency, not an architectural commitment.
• Feature areas it unblocks: checkout and pricing display, invoices and receipts, subscription/renewal date display, analytics and admin dashboards (compact numbers, percentages), marketing and campaign reporting, and per-user locale preferences. All are display concerns; none touch money movement.
• Per-market display quality as a product metric. Correct decimal separators, currency symbol placement, and date order are quiet conversion and trust levers in DE/FR/BR/JP. This package makes it cheap to A/B or audit those by locale.
• Explicit scope boundaries for the roadmap. This is a formatting wrapper. Currency conversion/FX, translated copy, country/currency reference datasets, phone-number metadata guarantees, and tax rules are not in scope — the PM assessment we inherited describing country/currency datasets does not match the actual package surface. Keep those as separate buy/build decisions so scope doesn't get conflated in planning.

When to Consider This Package

Adopt when:

• Your app must render numbers, currency, dates, or percentages in more than one locale, and you're currently sprinkling NumberFormatter boilerplate or string-concatenating symbols.
• ext-intl is reliably present across local, CI, and production — and you can pin the same base image everywhere so ICU output is consistent.
• You want a fluent, framework-native API (Intl::currency(1234.56, 'EUR', 'de-DE')) with per-call locale overrides, rather than threading a formatter config everywhere.
• You're willing to wrap it behind a small Formatter service — which you should do regardless, for testability and to keep an exit ramp open.

Look elsewhere when:

• You need anything beyond display: currency conversion, translated UI strings (use Laravel's lang files), country/address/phone-code datasets with validation, tax, or FX. Those are different products.
• You're formatting high-volume exports or reports. Formatter instances are expensive to construct; batch and reuse, or use the underlying intl classes directly.
• Your procurement posture requires a vendor-backed dependency with an SLA. This is a 3-star, zero-dependent, single-maintainer package with no prose changelog — 2.1.0 ships as a compare link only.
• You can't control ICU version drift. Output for the same input will differ across environments; that's the #1 source of "works on my machine" and, worse, flaky snapshot tests.

Risk posture: MIT, no transitive risk, tiny surface area. The correct mitigation is not a procurement review — it's (a) pinning the dependency, (b) wrapping it, and (c) accepting that forking or inlining it later is a small, bounded task.

How to Pitch It (Stakeholders)

To executives: We can make prices, dates, and percentages look native in every market we sell into for roughly a day of integration work, using a permissively licensed, well-understood helper. Better localized pricing display is a direct trust-and-conversion lever in EU, LATAM, and APAC. The dependency risk is minimal and reversible: MIT license, no lock-in, and the code we'd replace it with is small enough to own ourselves if the maintainer steps away. This is a low-cost enabler, not a platform bet.

To engineering: This is a thin fluent facade over PHP's intl extension — NumberFormatter and IntlDateFormatter with sane defaults and per-call locale overrides. Recommended usage: adopt it, but always call it through our own Formatter interface so tests can fake locale output and we keep one seam to swap. Non-negotiables for integration: ext-intl present in the Dockerfile and CI image; identical base image across dev/CI/prod for ICU parity; assert on structure (symbol present, digits grouped) rather than exact strings in tests; validate user-supplied locale and currency codes against a whitelist, since bad codes silently fall back instead of throwing; remember config:cache freezes published defaults and Octane needs octane:reload after upgrades. Before bumping to 2.1.0, run composer update ... --dry-run and diff 2.0.0..2.1.0 in vendor/, since there's no written changelog and a minor bump can still change defaults.