Releases: formatjs/intl-messageformat
v3.0.0
v2.2.0
v2.1.0
v2.0.0 — Return zero
v1.3.0 — CLDR 28
This minor release upgrades the locale data to CLDR 28.
v1.2.0 — Added Support for Escaping Backslashes
This minor release adds support for escaping backslashes (#109). The following example shows how a backslash can be included in the formatted message:
Choose either: one\\\\two\\\\three.
This will produce the following formatted message:
Choose either: one\two\three.
v1.1.0 — Added Ordinal Support, Updated Locale Data
This is feature release which adds support for selectordinal
arguments in message (#84), has updated locale data with support for new languages, and improves locale resolution.
Select Ordinal Arguments
selectordinal
arguments in messages are just like plural
arguments, expect the ordinal pluralization rules are used; e.g., to display which birthday your about to have:
It's your {year, selectordinal,
one {#st}
two {#nd}
few {#rd}
other{#th}
} birthday!
message.format({year: 30});
// => "It's my 30th birthday!"
Updated Locale Data
The locale data has also been vastly improved in the following ways:
- Added
pt-PT
plural rule function, which differs frompt
's. - Properly de-duplicate data for all CLDR locales by correctly traversing a locale's hierarchy of ancestor locales.
- Added data for the following languages:
aa, agq, bas, bh, ckb, dav, dje, dsb, dua, dv, dyo, ebu, ewo, guw, guz, hsb, ia, in, iu, iw, jbo, ji, jv, jw, kaj, kam, kcg, khq, ki, kln, kok, ksf, ku, lb, lu, luo, luy, mer, mfe, mgh, mo, mua, nah, nmg, no, nqo, nus, ny, pap, prg, qu, rn, rw, sbp, sh, sma, smi, smj, smn, sms, swc, syr, tk, tl, twq, vai, wa, wo, yav, yi, zgh
Improved Locale Resolution
This release also includes improvements for how locales are resolved. Here are some details of these changes:
-
If no extra locale data is loaded, the locale will always resolved to
en
. -
If locale data is missing for a leaf locale like
fr-FR
, but there is data for the root,fr
in this case, then its root will be used. -
If there's data for the specified locale, then that locale will be resolved; i.e.,
var mf = new IntlMessageFormat('some message', 'en-US'); assert(mf.resolvedOptions().locale === 'en-US'); // true
-
The resolved locales are now normalized; e.g.,
en-us
will resolve to:en-US
.
v1.0.4 — Fixed Support for ES3 + Browserify/Webpack
This patch release actually fixes #90 so that the Browserify/Webpack output is compatible with ES3 environments. The previous release had .default
s in the transpiled CommonJS modules, the es6-module-transpiler
has been updated to fix that, and this release contains those fixes.
v1.0.3 — Support for ES3 + Browserify/Webpack, Fixed Minified Source Maps
This patch release fixes #90 so that the Browserify/Webpack output is compatible with ES3 environments. Source maps for .min.js
files have also been fixed so that they now include the actual source code.
v1.0.2 — Support for Browserify/Webpack
This patch release improves support for using Browserify or Webpack to bundle intl-messageformat
. Since the context of these tools is to bundle for the browser, this release will only include the English locale data in the bundle by default. (Previously the data for all locales would be included when bundling with Browserify or Webpack.)
When you need to support another locale in your app and you're using Browserify or Webpack, we recommend the following approach:
// app.js
var IntlMessageFormat = window.IntlMessageFormat = require('intl-messageformat');
// ...
<script src="/app.bundle.js"></script>
<script src="/intl-messageformat/dist/locale-data/fr.js"></script>
This will expose IntlMessageFormat
as a global object in the browser, allowing you to load the script for the locale data you need for the page or current request.
Source Maps Improvements
This release also includes improvements to source maps, making debugging easier.