I'm starting a new project and I intend to implement internationalization using the library. I'd also like to integrate messageformat.js with Handlebars and I found some references to this in the documentation. Is there any ETA on the implementation?

I could try to do it myself, but I'd need some indications on where to start to do it right.

Thanks in advance!

Hello

I have to format a string including a number of hours and a label (in french) : {HOURS, plural, one{# heure} other{# heures}} giving me well formated string with integers : 0 heure 1 heure 2 heures

Problem is that when I have a decimal value between 0 and 1, it displays : 0.5 heures instead of 0.5 heure

I tried with zero{} and =0{} without success, it falls back automatically in the other{} format. I didn't find any <1{} syntax. How can I do that ?

ps: I could use the SelectFormat syntax with a new boolean variable telling me wether HOURS is a decimal between 0 and 1 ... but is there a more elegant solution ? Thanks

As per discussion under #539 Message formatting dependant on base text direction I am submitting here the addition of predefined number formatting function enforcing Bidi Text Direction and Structured Text by using UCC. The upgrading qualities are:

• Prevents intermingling of text contained in placeholders with the rest of message text.
• Maintains the integrity of Bidi text flowing according to directionality of language script.
• Enforces 'contextual' Bidi text direction on placeholder content
• i.e. text direction is defined by first strong character of placeholder text -
• 'right-to-left' if first strong character is bidi (Hebrew/Arabic) and 'left-to-right' othervise.
• For reference to Bidi strucctured text see: http://cldr.unicode.org/development/development-process/design-proposals/bidi-handling-of-structured-text
• For reference to Bidi text direction see: http://w3-03.ibm.com/globalization/page/publish/4353

Please note that this submission constitutes the first step, the next would to be step is contribution to Globalize (https://github.com/jquery/globalize) with objective to make this Bidi formatter available for Globalize.messageFormatter. The intended contribution to Globalize is to:

• add parameter (object containing formatters) to 'messageFormatter' API and pass it to 'MessageFormat' Globalize.prototype.messageFormatter = function( path, fmt ) { .................... formatter = new MessageFormat( cldr.locale, pluralGenerator, fmt ).compile( message );
• expose predefined formatters Globalize.prototype.messageFormatter.formatters = MessageFormat.formatters;

If you are open to changing your API slightly (approximating to Strawman Draft)'s, we could have something like the below.

var messageFormat = new MessageFormat( locale, pattern [, fieldFormatters] );
var formattedMessage = messageFormat.format( params );

• locale is a string locale. E.g., en. (no changes to what you currently have)
• pattern is the message-format pattern. E.g., {count, plural, one{...} other{...}}. (no changes to what you currently have)
• fieldFormatters a key-value pair of fns. E.g., { plural: <fn>, number: <fn> }. (it extends the way you currently get plural)

The optional fieldFormatters could be merged with a static/global/default one, e.g., MessageFormat._fieldFormatters.<locale>. So, you can keep setting the default plural function for English on your bundle.

Production mode (precompilation)

A formatted message is (obviously) a result of the generated formatter, which is the compiled pattern processed by two set of functions: (a) [runtime functions](what's currently been called .functions%28%29) and (b) the fields functions (currently, the plural function).

The generated formatter doesn't embed the runtime functions nor the fields functions (which also makes sense to me). So, we can say the generated formatter is a function that depends on both of them:

messageFormat.precompile(); // => function( runtimeFns, fieldsFns ) {
//  return <the generated formatter( params )>;
//}

The runtime bundle

Having distinguished the three layers above, generating the runtime bundle is not difficult. It could be accomplished in a variety of different ways:

• Embedding everything together similar to the current example/en/i18n.js

Or:

<script src="messageformat.runtime.js"></script>
<script src="my-plural.runtime.js"></script>
<script>
  MyGlobalName[ "key" ] = <precompiled>( MessageFormat, { plural: myPlural } );
</script>

Or:

// app.js
require.config({
  paths: {
    messageformat: "messageformat.runtime"
    "my-plural": "my-plural.runtime"
  }
});

require([ "./my-precompiled-message-formatter" ], function( messageFormatter ) {
  var message = messageFormatter({ count: 1 });
});

// my-precompiled-message-formatter.js
define([ "messageformat", "my-plural" ], function( MessageFormat, myPlural ) {
  return <precompiled>( MessageFormat, { plural: myPlural } );
});

OBS:

It's the plural library problem to generate its own plural runtime. The same way, it's the number formatter problem to generate its own runtime, the same for date formatter, currency formatter, etc.

So, I may have ended up going down a bit of a rabbit hole when I fixed #134 while thinking of #132, and put together this little proposed set of changes. It includes changes to, well, nearly everything except for the parser. The source code documents itself pretty well, but here's an overview of the changes:

Constructor

Takes in a single locale parameter, which can be a string, array or object; the last form effectively includes the functionality of the previous second parameter pluralFunc. The semantics of locale are also a little different, as the concept of fallback locales is dropped, and instead having multiple entries creates a fully multi-lingual MessageFormat object. The formatters are dropped from the constructor; their addition is now with a chainable addFormatters method. They're also much better documented.

compile()

With object input, the output is no longer a function, but an object with a similar structure as the input, with each messageformatted string replaced by a corresponding function. The top-level object has a toString method that works a bit like previously, except better -- it defaults to an UMD wrapper, and can output e.g. ES6 module code. When used with multiple locales, the locale is auto-detected from the object keys. The second optional parameter locale can be used to force a single locale, or to select one if the constructor was originally called with no parameters.

Runtime

The included runtime methods are flattened, and only included if actually used. See the updated example for the new default output, and note that it's missing the select function as that's not included in any of the compiled functions. The flattening does mean that some locale names need to be fiddled with to make them valid non-reserved JS function names.

bin/messageformat.js

Effectively completely rewritten and simplified, given the new compile().toString() output and options.

Altogether, this is a whole pile of breaking changes, and will need a new major version. Perhaps it'd be time to consider a 1.0 release?

I need to support some translators with writing nested select and pluralization rules. One option we're looking into would be to have a JavaScript-based app where they can put their message into a text form and would get one or more of the following:

• Syntax check: Is their message valid? If not, can we tell them where it's broken or can we fix it automatically?
• Pretty printing: For example, indentations for nested selects. Or highlighting of fixed string parts (like we developers are used from IDEs)
• Testing: Can we automatically extract all the variables used in a message and allow users to provide values for them (or select radio controls for different "select" cases) so they can then get a live-preview of what the resulting message would be?

Would messageformat.js be a good base for building such a tool? Can it already produce the necessary information by parsing the message strings?

Do you know of any other libraries (or off-the-shelf tools) that could help me solve this?

Thanks!

Well, it's more a general question than a real issue.

I currently use a JavaScript implementation of Gettext in my project and plan to switch to messageformat.js.

In the Gettext world it's rather easy to edit translations :

• both the original and translated strings are in the same file
• Poedit eases the process when working with independent translators
• merging po files can be done with msgmerge...

My problem: in my test with messageformat, I have two JSON files (french and english translations). It makes the translation process harder since I have to switch between those files to check what's written in french or in english.

I would like to know that king of workflow/tool are used to keep the JSON files up-to-date (more specifically when working with independent translators).

Thanks for making messageformat =)

Benoit

This is a follow-up to discussion in #65, and it implements ICU's simpleArg syntax in a rather liberal fashion. Effectively, it makes syntax like {var, fn[, args]*} call a user-definable function fn, passing it the value of var, the locale(s), and args.

Formatting functions for ICU's number, date and time are included, making use of Intl.NumberFormat and Intl.DateTimeFormat. They are a part of ECMA-402, but are not yet available in node by default (see joyent/node#7676), though their support in browsers is getting to be pretty good. There is a node polyfill available, though.

The spellout, ordinal and duration argTypes are not supported, as they're way more complicated and without support via Intl or in fact any JavaScript library that I could find. ICU uses the rules defined here using this syntax to manage them, and implementing all that in JavaScript probably ought to stay outside the scope of messageformat.js.

As number includes the argStyle currency, it currently defaults to USD. To use something else, you should set mf.currency before calling mf.compile(), like so:

> var mf = new MessageFormat('en');
> mf.currency = 'EUR';
> var mfunc = mf.compile("The total is {V,number,currency}.");
> mfunc({V:5.5})
"The total is €5.50."

Or by setting the formatter function directly:

> var mf = new MessageFormat('fi');
> var mfunc = mf.compile("Yhteensä {V,number,currency}.");
> mf.runtime.fmt.number = MessageFormat.format.number({currency:'EUR'});
> mfunc({V:5.5})
"Yhteensä 5,50 €."

You can also define your own functions:

> var mf = new MessageFormat( 'en' );
> var mfunc = mf.compile("This is {V,uppercase}.");
> mf.runtime.fmt.uppercase = function(v) { return v.toUpperCase(); };
> mfunc({V:"big"})
"This is BIG."

The {V,fn,...} format accepts any number of comma-delimited parameters that are passed on to fn(v,lc,p). If there's just one parameter, it's passed as a string; otherwise p is an array, or null for none.

The default formatting functions are automatically included in mf.runtime when encountered by mf.precompile() (as seen in the first example above); additional auto-loading formatting functions may be added to MakeFormat.format.

To make all of the above work properly, I needed to redefine mf.lc to be an array, which gets passed on to the Intl methods. This meant that the MessageFormat constructor got reworked, and now accepts a string or an array as a first locale parameter. Semantics with string input are the same as before: fallback are successive stages of dropping [-_][^-_]+ parts from its end. If locale is an array, though, it's taken to be an ordered list of locales to try, like here.

There's also a new method MessageFormat.pluralFunc(locale) which wraps make-plural.js usage. It also tries to access root.MakePlural, which means that usage in a browser environment no longer requires manually setting MessageFormat.locale values, so this works:

<script src="path/to/messageformat.js"></script>
<script src="path/to/make-plural.js"></script>
<script>
  var mf = new MessageFormat('en');
  var mfunc = mf.compile("The total is {V,number,currency}.");
  console.log(mfunc({V:5.5}));  // "The total is $5.50."
</script>

mf.runtime is also simplified a bit, getting rid of two of the utility functions and putting the formatting functions into their own namespace mf.runtime.fmt. I also renamed mf.runtime.lc to mf.runtime.pf as it holds plural functions. It's now a separate object from MessageFormat.locale, and only contains the plural functions that are explicitly included.

Questions to consider

• [x] Should MessageFormat() take as a third parameter an object of formatting functions?
• [x] Should MessageFormat.format be renamed to something more specific?
• [x] Should MessageFormat.locale also be renamed to more clearly refer to the plural functions it contains?
• [x] Are we ok depending on Intl? Should that dependence be explicit, and/or checked at runtime?

Working towards better documentation, I added JSDoc commentary throughout the source. In addition to being readable in situ, it compiles to HTML pretty cleanly.

While at it, I cleaned up the source in a couple of places, most visibly moving mparser = require('./message_parser') to be within MessageFormat._parse, and removing the _ prefixes of the runtime functions.

This could be left as is, or we could add jsdoc as a dependency, along with a suitable config file and a make rule. Here's the minimal conf.json I've been using so far:

{
  "source": { "include": [ "lib/messageformat.dev.js" ] },
  "plugins": [ "plugins/markdown" ]
}

Regarding the copyright statement, I went for now with "2012-2015 Alex Sexton and other contributors". Is that all right?

I'm working on a dust helper for mf, and because this helper needs to work server and browser-side, I need to take advantage on the i18n.js file.

Currently (v0.1.8) precompiled functions are only exposed to the window object.

In order to be able to take advantage of that file but server-side too, I think it could be great if we could make this file a commonJS module, with this pattern:

var o = {};

o['my/super/template'] = {
  foo: function () {...},
  bar: function () {...}
};
...

// CommonJS and browser exports
this["i18n"] = this["i18n"] || o;
if (typeof module !== "undefined" && module !== null) { // check module variable exists
  module.exports = this["i18n"];
}

Like this, browser-side we could:

<script src="locale/en.js"></script>
<script>
alert(i18n['my/super/template']['foo']());
</script>

but also server-side:

var i18n = require('./locale/en.js');
console.log(i18n['my/super/template']['foo']());

I've forked the v0.1.8 for my needs here, but could be great if you could bring that modification to your master.

Fixes #241

This adds a new method MessageFormat#setArrayOutput(), which makes compiled functions return arrays instead of strings, allowing for variable values to not be stringified. Some examples:

const mf = new MessageFormat('en').setArrayOutput()

mf.compile('simple message')()
// ['simple message']

const obj = { foo: 'bar' }
mf.compile('objectively, {obj} is an object')({ obj })
// ['objectively, ', obj, ' is an object']

mf.compile('select {num, plural, one{one} other{#}}')({ num: 42 })
// ['select ', [42]]

Bumps json5 from 2.2.1 to 2.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps loader-utils from 2.0.3 to 2.0.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Since adopting @messageformat/core we've been running into various issues for some users on old browsers. For most of the issues the combination of Babel and polyfills handles it, but it appears this specific code is generating a string that contains an arrow function that's being passed to eval(), which of course Babel can't deal with. Trivial change, tested on Chrome 38 on our game (https://worlds.frvr.com, still have the old version live), mostly just had to change a bunch of test case outputs to match.

Fixes: https://github.com/messageformat/messageformat/issues/361

This is a sketch to fix 361. I can see it being desirable to hide the inner recursive parameter by creating an "outer" and "inner" function, but I opted for the most simple approach.

While authoring https://github.com/messageformat/messageformat/pull/360, I noticed a potentially unexpected edge case while using the * operator:

Let's say I'm authoring some messages, and I want to be overly terse:

const messagePacks = {
    "en": {
      es: "Estimation Date: {date, date, ::EEEMMMd}",
      fi: "Financial Incentive Date: {date, date, ::EEEMMMd}",
    },
  };

If I were to compile this against the new MessageFormat("*") invocation, I'm going to get very unexpected output. Namely, spanish and finnish localized dates.

See the repro here: https://github.com/dpchamps/mf-locale-collision-repro

Idea for a fix: we could add an optional arg to compile to indicate isRecursing, and then not pull from the plurals at all.