Intl Extra Laravel Package

Product Decisions This Supports

• i18n as a template-layer capability, not a backend project. The package exposes twelve locale-aware filters (format_currency, format_number, format_date/format_datetime/format_time, country_name, currency_symbol, language_name, locale_name, timezone_name, country_timezones). That means a PM can scope "show prices, dates, and country names correctly for EU/APAC users" as a design-and-template task rather than a multi-sprint service rebuild.
• Feature scoping: localization depth. It forces an explicit product decision between formatting localization (numbers, dates, currency, region names — this package's full scope) and content localization (translated strings, plurals, RTL). This package only does the former. Roadmap items that are really about translation memory, editorial workflow, or machine translation should not be funded through this dependency.
• Build vs. buy on formatting primitives. Currency symbols, timezone lists, and locale-correct date patterns are data problems, not logic problems. Delegating them to PHP's ICU-backed intl avoids maintaining a currency/locale table in-house — a small but real ongoing maintenance line item removed from the backlog.
• Market-entry sequencing. country_timezones and timezone_name make "launch in N new countries" cheaper to demo and QA: localized receipts, invoices, admin timestamps, and account settings screens can be validated per-locale without new endpoints.
• Use cases that are genuinely a fit: transactional email templates rendered outside Blade, exported PDFs/invoices, admin dashboards showing user-local timestamps, and pricing/plan pages that must display the same number differently per market.
• A decision this package does not support: choosing Twig over Blade. Adopting it for its own sake imports a second templating language into a Laravel codebase. Treat "we already render Twig somewhere" as the precondition, not the conclusion.

When to Consider This Package

Adopt when all of these hold:

• The surface you're localizing is already rendered by Twig — standalone Twig for mailers/PDFs, a Symfony or Lumen component in the estate, or an existing twig/bridge integration. This is the gating criterion; nothing else compensates for it.
• You need output formatting only: currency, numbers, dates, region/currency/language display names. No translated copy, no plural rules in the template layer.
• PHP's intl extension is present in every target environment (it normally is, but confirm for container images, CI, and any serverless runtime).
• The blast radius is contained — a handful of templates, not the primary view layer — so a locale bug is a formatting bug, not a broken page.
• You're comfortable owning a dependency that is small, MIT-licensed, and maintained by the Twig core team but has very low downstream adoption (near-zero dependents reported) — meaning you'll be debugging largely from source and ICU docs.

Look elsewhere when:

• The stack is Blade. Laravel's default view layer does not consume Twig extensions. Bridging Twig into Blade, or reimplementing these filters as Blade directives, converts a one-line dependency into a bespoke, permanently-owned abstraction. In pure-Blade Laravel, this is the wrong tool regardless of how good the filters are.
• You need translation, not formatting. Reach for Laravel's own __()/@lang, symfony/intl/symfony/translation, or a translation platform. This package will not move a translation roadmap forward.
• Carbon and Laravel's helpers already cover ~80% of the need. Number::currency(), Number::format(), and Carbon's locale-aware formatting are first-class, Blade-native, and already installed. The honest test: enumerate the specific templates that Laravel's helpers cannot serve, and see whether that list is long enough to justify a second templating engine.
• Rendering must run at the edge or in a non-PHP runtime. The package is a thin wrapper over PHP's intl; there is no path off the PHP runtime.
• Performance-critical loops. Locale formatting inside a large {% for %} can measurably slow rendering. If the volume is high, format in PHP once and pass values in.
• You need a hard support contract. Community-only support, sparse issue traffic, and no vendor SLA.

Two risk notes to carry into any adoption decision: the v3.26.0 release carries a security fix (CVE-2026-46629, unbounded memoization of date/number formatters), which is a good sign of maintenance and also a reminder that this dependency needs to be in the patch-tracking rotation, not pinned-and-forgotten. And confirm the actual Twig major version your estate runs against — the extension's compatibility track follows Twig, and a Twig major bump is a coordinated upgrade, not a routine one.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: "This is a small, free, MIT-licensed add-on that makes dates, prices, and country names display correctly for users outside the US, directly in our templates. It doesn't add a service or a vendor; it removes work from the backlog. The catch is that it only helps on the parts of our product that use Twig templating — so I'd frame approval as 'localized formatting for those surfaces,' not 'we're now internationalized.' If the ask is broader international expansion, this is one line item, not the program."

For engineering — the honest framing: "It gives us ICU-backed formatting filters inside Twig: format_currency, format_number, format_date*, plus lookup filters for country, currency, language, locale, and timezone names. Value is real but scoped: this is a formatter, not a translation layer, and it requires Twig — so it's a fit for mailers, PDFs, and any existing Twig surfaces, and a non-starter for Blade views unless we're prepared to own a bridge. Cost is one Composer dependency and an extension registration; the carrying cost is that it's a low-adoption package we'll mostly debug from source, it needs to sit in patch tracking (there was a formatter memoization CVE fixed in v3.26.0), and locale correctness needs actual per-locale test cases, not just a smoke test in en_US. My recommendation: pilot on non-critical email templates, measure the number of Blade templates we'd still have to handle separately, and decide from that number whether to expand or stop."

For engineering, the decision I'm asking for: approve a time-boxed pilot on one Twig-rendered surface (transactional email is lowest risk), with the success criteria being (a) the count of remaining Blade templates that need equivalent formatting and (b) whether Laravel's native Number/Carbon helpers already cover them. If (b) resolves most of (a), we close this out and use what we already have.