MessageFormat 2 in i18next: state of the migration (May 2026)

TL;DR (May 2026): MessageFormat 2 (MF2) is the new Unicode standard for localized messages — final candidate since March 2025, spec-stable. But adoption is still early. The i18next-mf2 plugin gets 6 weekly npm downloads. The underlying messageformat library gets 355,051. For most i18next users today, the answer to "should I migrate?" is "not yet — but understand what's coming."

What is MessageFormat 2?

MessageFormat 2 (MF2, formally messageformat-2.0) is the new Unicode standard for representing localized messages. It is maintained by the Unicode Common Locale Data Repository (CLDR) Technical Committee and reached Final Candidate status in March 2025, with refinements in LDML 47 and 48 (October 2025). The specification is now stable. For a developer-focused overview, Igalia's MessageFormat 2.0 introduction (May 2024) is the most accessible read.

MF2 is the successor to ICU MessageFormat (sometimes called MF1 retroactively), the format the i18next ecosystem has used via the i18next-icu plugin for over a decade. (For broader context on how JavaScript i18n formats compare, see our overview of JavaScript i18n formats.)

What MF2 actually changes — side-by-side

The clearest way to see the difference is a real example. Consider a plural message with interpolation.

ICU MessageFormat 1

{
  "items": "{count, plural, =0 {You have no items.} one {You have one item.} other {You have {count, number} items.}}"
}

The whole message is one curly-brace expression. The variable, the selector, and the variants are all inline.

MessageFormat 2

.input {$count :integer}
.match $count
  0       {{You have no items.}}
  one     {{You have one item.}}
  *       {{You have {$count} items.}}

MF2 splits the message into three explicit parts:

1. .input declarations name and type the variables (here $count is an integer).
2. .match declares which variable drives selection.
3. Variants are listed under explicit selector values; * is the fallback (replaces MF1's other).

For simple cases the verbosity feels like overkill. For complex cases — gender + plural + format combinations, multiple selectors per message, message reuse with .local declarations — MF2 becomes meaningfully cleaner. Full syntax reference lives in the ICU User Guide for MessageFormat 2.

The npm download story

A direct way to measure i18next-side adoption: compare the official i18next-mf2 bridge, the underlying messageformat reference library, and the established i18next-icu plugin (which implements MF1).

Two things stand out:

1. messageformat has reach — but mostly as a transitive dependency or in non-i18next ecosystems. Not a direct MF2-on-i18next adoption signal.
2. i18next-icu (MF1) is growing — roughly tripled over the past year, from ~100k to ~300k weekly. The MF1 install base in the i18next ecosystem is healthy and expanding, not shrinking. That's the audience MF2 would eventually need to migrate from.
3. i18next-mf2 is at ~10 weekly downloads. Functionally zero traffic so far — closer to "spec-curious developers" than to "production projects shipping."

Read: the standard exists, the runtime exists, the i18next MF1 install base is healthy and growing — but the i18next side has not started migrating to MF2 yet.

Why adoption is slow

Three reinforcing factors:

1. TC39 Intl.MessageFormat is stuck. Per issue #49 on the TC39 proposal-intl-messageformat, the committee asked for roughly a dozen organizations to be using MF2 in production before advancing to Stage 2.7. That gating signal hasn't been met.
2. No major framework default has switched. FormatJS / react-intl are still ICU MessageFormat 1. Lingui is MF1. Tolgee is MF1 in its ICU docs. i18next removed legacy interpolation.format in v26 but kept the built-in Formatter — not a MF2 migration.
3. No competing TMS has shipped MF2 support. Crowdin's 2026 blog has zero MF2 mentions across 13 monthly recaps. Lokalise's MF1 guide ranks fine; no MF2 announcement found. Same for Phrase and Transifex.

Net: the spec is stable but the gravitational pull toward adoption hasn't started.

Should you migrate to MF2 today?

Most teams: no, not yet.

ICU MessageFormat 1 still works, has wide framework support, has documentation everywhere developers look, and has been battle-tested for over a decade. Until at least one of FormatJS, Lingui, or a major framework defaults to MF2 — or until TC39 advances to Stage 2.7 — migrating now means owning the rough edges yourself.

Migrate now if you fit one of these:

• Brand-new project. You're starting fresh and don't have an existing message library. Picking MF2 means future-proofing without rewrite cost.
• Heavy use of complex selectors. Gender + plural combinations, nested selectors, multi-variable matching — these are MF1's pain points and MF2's strengths.
• You want to be early. You have the engineering bandwidth to deal with sparse documentation and limited tooling, and the strategic interest in being ahead.

For everyone else, the right move is: stay on ICU MessageFormat 1, watch the inflection signals, and be ready to migrate when the ecosystem moves.

How Locize handles this today (and tomorrow)

Three things matter for a TMS in this transition:

1. Format-agnostic storage today. Locize stores translation messages as text. Whatever format you write — ICU MessageFormat 1, MessageFormat 2, plain interpolation, or anything else — is preserved verbatim through the editor, the CDN, and the API. See supported i18n formats, the pluralization reference, and the full file-format support matrix.
2. No vendor lock-in to a specific message format. The i18next-mf2 plugin reads Locize-served messages the same way i18next-icu does. When MF2 adoption inflects and you want to migrate, you can update messages in-place in Locize — no TMS change required.
3. First-class MF2 editor support coming when MF2 is accepted. Internal work on a Locize-side MF2 message handler is already underway. The plan: ship full first-class MF2 support in the editor (syntax-aware editing, variant tooling, type-checked placeholders) when at least one of the inflection signals below triggers — TC39 advances, a major framework defaults to MF2, or a critical mass of i18next users start migrating. No date promised; the trigger is ecosystem-readiness, not a calendar.

In other words, picking Locize today doesn't lock you into MF1 or MF2 specifically. Both work now; first-class MF2 support is on the runway when the ecosystem is ready.

What to watch for in 2026–2027

The signals that meaningful adoption is starting:

• TC39 Intl.MessageFormat advances to Stage 2.7 or Stage 3. This is the clearest signal that production deployments have crossed the dozen-orgs threshold.
• FormatJS or Lingui ships MF2 as a default (or first-class) option. Either would represent a significant ecosystem signal.
• A major SaaS or e-commerce platform publicly documents a MF2 deployment. "We use MF2 in production at $company" — even a single one — would shift the conversation.
• i18next-mf2 weekly downloads cross ~1,000. Mechanical signal: the i18next-side bridge moves from "spec-curious developers" to "real projects shipping."

We'll publish a follow-up post when any of these triggers. For now, this is where things stand.