Polyfill Intl Messageformatter Laravel Package

Product Decisions This Supports

• Shipping localized, human-quality copy without a platform mandate. ICU MessageFormat is the standard way to express pluralization ("1 item / 3 items"), gender and select-based variants, and — as of v1.43.0 — ordinals ("1st, 2nd, 3rd" via selectordinal). This package supplies MessageFormatter and the msgfmt_* functions when PHP's ext-intl is absent, so a localization feature can ship without making a C extension a hard deployment requirement.
• Build vs. buy: buy (and don't build). Writing an ICU MessageFormat parser in-house is a known trap — plural rules, ordinal rules, nested selects, escaping, escaping-adjacent list formatting, and locale fallback are deceptively deep. Adopting a maintained polyfill is the low-cost, low-risk answer versus a bespoke formatter or a homegrown string-replacement scheme.
• Deployment-target flexibility. It decouples "we support translated messages" from "every host, container image, and serverless runtime has intl compiled in." That materially widens the set of viable hosting and packaging options, particularly for distributed apps, plugins, or libraries installed into environments you don't control.
• Roadmap sequencing for international expansion. Markets with rich plural and ordinal categories (Slavic, Arabic, Celtic, plus English-style "1st/2nd/3rd" UI) are exactly where naive %s-substitution breaks. selectordinal arriving in this release removes a previously common reason to punt on rank/position/step copy ("your 3rd attempt", leaderboards, checkout flows) or to hardcode English ordinal suffixes. This dependency is the enabler that lets i18n work be scheduled as a product feature rather than blocked behind an infrastructure ticket.
• Risk reduction for a class of support bugs. Missing-extension failures typically surface as fatal errors or silently degraded strings in production, not in development. A polyfill converts a hard environment dependency into a soft, testable fallback. v1.43.0 also lands correctness fixes in integer rounding and English list patterns — the kind of off-by-one and separator bugs that reach users as "the app can't count / can't punctuate" defects.
• Commoditized infrastructure, not a differentiator. This should be treated as plumbing: no competitive advantage, but a cheap hedge. It carries no per-seat or per-call cost (MIT), negligible footprint, and no vendor lock-in.
• Signal caveat for prioritization: star count understates maturity — it is a Symfony-maintained polyfill, usually pulled in transitively rather than chosen directly. Judge it on the maintainer and release cadence (active, with a feature-bearing release here), not on community popularity.

When to Consider This Package

Consider it when:

• Your code (or a dependency you use) formats messages through MessageFormatter or msgfmt_format_message, and ICU plural/select/selectordinal syntax is part of the copy strategy. If ordinal copy ("3rd", "21st") is on the roadmap, v1.43.0 is the first release where the polyfill covers it — previously that was a hard argument for requiring ext-intl.
• ext-intl is not guaranteed across all environments: shared hosting, customer-managed on-prem installs, minimal Docker base images, CI runners, or serverless platforms.
• You distribute a library, plugin, or theme intended to run in environments you don't provision — broad compatibility is a product requirement.
• You want deterministic behavior between developer machines and production without adding image-build steps or ops coordination.
• You're already on Symfony components or a framework that resolves polyfills automatically — the marginal cost is effectively zero.

Look elsewhere, or push back, when:

• You control the runtime end to end and can simply declare ext-intl a documented platform requirement. Native intl is faster and more spec-complete; the polyfill becomes dead weight.
• Message formatting sits on a high-throughput hot path (per-request rendering at scale, batch generation of millions of strings). Polyfilled formatting is meaningfully slower than the C implementation — benchmark before adopting, and note that ordinal rules add per-message work.
• You need intl well beyond message formatting — full collation, transliteration, NumberFormatter, IntlDateFormatter, timezone handling, locale negotiation. The release notes show adjacent polyfill work (grapheme, Collator sorting, iconv_*) receiving fixes, but that is maintenance of shared polyfill internals, not a commitment to full parity. If those features are central to the roadmap, make the extension a requirement instead of accumulating polyfills.
• You depend on exact ICU parity: custom formats, specific error codes, edge-case locale fallback, or locale-specific list punctuation. Polyfills approximate; v1.43.0 explicitly corrects English list patterns and integer rounding, which is a reminder that parity gaps exist and are found over time. Verify against the native extension with a parity test suite before committing.
• Your i18n library ships its own formatter and you'd end up with two formatting paths — duplicated behavior is worse than a missing extension.

How to Pitch It (Stakeholders)

For executives: We can deliver translated, grammatically correct product copy — including plural, gender, and now ordinal variants ("1st, 2nd, 3rd") — without adding a server prerequisite or an infrastructure project. This package is a free, MIT-licensed compatibility layer maintained under the Symfony project that reproduces PHP's built-in internationalization message formatting when that extension isn't installed. The latest release closes a real product gap: ordinal formatting, which powers rank, sequence, and progress copy, is now supported by the polyfill, and it fixes counting and list-punctuation defects that would otherwise reach customers. The commercial value is speed to market in non-English locales and a smaller deployment checklist: fewer environment-specific failures, no per-environment configuration, no licensing cost. The risk is contained — a well-scoped, actively released dependency with a narrow surface area, removable the day we decide to standardize on the native extension.

For engineering: Drop-in, no application code changes — it registers the same class and function names, typically guarded by function_exists, so behavior is identical where intl already exists. Install is transitive or a single Composer line; MIT license; maintained by Symfony with active releases. Two conditions to accept: (1) we add a CI job that runs the suite both with and without ext-intl, now including at least one selectordinal case, so polyfill drift can't reach production silently; and (2) if formatting ever lands on a high-volume path, we revisit and promote ext-intl to a stated platform requirement. Treat it as inexpensive insurance now, with a clear exit criterion.