Laravel Intl Laravel Package

Product Decisions This Supports

• Market entry / localization roadmap. Whether to ship a locale-specific experience (currency symbols, decimal separators, date and number conventions) this quarter or defer. This package makes "localized formatting" a small line item rather than a multi-sprint workstream, which changes the cost side of the expansion equation.
• Build vs. buy for formatting logic. Formatting numbers, currencies, percentages, ordinals, spellouts, country names, and phone numbers by hand is a classic source of quiet, high-volume bugs. This is a "buy" (well, adopt) decision: a thin Laravel-idiomatic wrapper over PHP's ext-intl (ICU) and libphonenumber, instead of a bespoke NumberFormatter helper set.
• Feature-level decisions it unblocks:
  • Localized pricing and checkout surfaces — Intl::currency()/Intl::number() for display, with correct grouping and symbol placement per locale.
  • International signup and KYC flows — Intl::phoneNumber() for parsing, formatting, and validating numbers against a region.
  • Country/region pickers and address forms — ISO-code-to-name lookups instead of a hand-maintained country list.
  • Microcopy polish — ordinals ("3rd"), spellout ("three"), and percentage formatting that reads native rather than translated.
• Scope discipline. It supports a "localize presentation, not domain logic" decision: keep money arithmetic in a proper money library and use this only at the edges where values become strings for humans.
• Risk and sequencing decisions. Adoption implicitly commits the roadmap to ext-intl being present in every runtime (local, CI, containers, serverless). That is a platform decision, not just a library choice.

When to Consider This Package

Adopt when:

• You are on a supported Laravel version and are actively adding one or more non-default locales.
• You need several of its concerns at once — numbers, currency, phone numbers, country names. The value is consolidation; a single concern usually has a sharper, narrower alternative.
• Your team is small and would rather not own ICU formatting edge cases (Arabic plural forms, Indian digit grouping, Swiss apostrophe separators).
• ext-intl is already available or trivially installable in your deployment targets.
• Presentation-layer formatting is acceptable — you are producing display strings, not doing money math or storage.

Look elsewhere or build thin yourself when:

• You only need translated strings. Laravel's native localization already covers that; this adds nothing.
• You need full ICU message formatting with embedded plural/select/gender rules — reach for a MessageFormatter-style solution rather than attribute formatters.
• You need currency arithmetic, allocation, or rounding guarantees — use a dedicated money library (brick/money, moneyphp/money) and treat this package as display-only.
• You only need phone handling — a dedicated phone package or libphonenumber-for-php directly is a smaller surface.
• Your formatting is primarily client-side — duplicating format logic server-side and in JavaScript invites drift; pick one source of truth.
• Runtime constraints make ext-intl painful (some minimal container images, certain serverless builds), or you have hard dependency-governance requirements. Verify maintenance activity, release cadence, and issue responsiveness directly — the supplied metadata shows no stars or dependents, and a lightly-adopted, single-maintainer wrapper is a real sustainability consideration for a long-lived product surface.
• You need locale-aware sorting, collation, transliteration, or timezone math beyond display — confirm coverage explicitly before assuming it.

How to Pitch It (Stakeholders)

For executives (one paragraph): Localizing for a new market usually means re-doing how prices, numbers, dates, and phone numbers are displayed. Getting that wrong is cheap to ship and expensive to fix — mistyped prices and rejected phone numbers show up directly in conversion. This package lets the team deliver those conventions using the same standards-based formatting engine that browsers and operating systems use, instead of writing and maintaining custom formatting code. The cost is one small dependency and a runtime requirement (ext-intl) our platform team should confirm. It is a low-cost enabler for market expansion, not a differentiator on its own — the decision is really "are we localizing this quarter, and do we want this to be a two-day task or a two-week one."

For engineering (summary): A Laravel facade over ext-intl/ICU plus libphonenumber, offering number, currency, percentage, ordinal, spellout, country-name, and phone-number formatting. It removes hand-rolled formatters and their test suites from our codebase. Integration is small: composer require, confirm ext-intl in every environment, pin the version, and add snapshot tests for our target locales. Guardrails to agree up front: use it for display only, never for money arithmetic or persistence; keep one formatting layer per surface (don't mirror this in the frontend); and check ICU version parity between dev, CI, and production, since output can differ across ICU releases. We should also do a short health check on the upstream project — activity, open issues, and release history — before treating it as long-term infrastructure, and be prepared to fall back on direct NumberFormatter/IntlDateFormatter calls if it stalls, which is a contained migration because the API is thin.