Notifications/New formatter system

This page contains developer documentation about the new formatter system introduced in.

Each notification type needs to implement the  class. That implementation will have access to the  and   it should be formatted in. The goal is to require each notification type to expose a model, and leave it up to each formatter (Flyout, Email, etc.) to put it in the right format for display.

The URL may be a relative one, and the link text should not be escaped yet. Like before, the URL may be relative, and the link text should not be escaped yet. An arbitrary number of secondary links can be provided.
 * - Whether the model is able to represent the notification (default: ). Implementations might return   here if the page the notification was on was deleted for example. If this returns , no other methods will be called.
 * - Returns the message key for the header (default: ). The default should work for most notification types, only cases where the text depends upon other values (like mentions being able to detect the section) should this be overridden.
 * - Returns a  object for the header. The default implementation adds the formatted username and gender username of the event's agent as parameters to the message, and then returns it. Subclasses should call the parent implementation, and then add extra parameters. For example:
 * - Returns a  object for the body or   if the notification has no body. The default implementation returns.
 * - Should return an array with the following format:
 * - (Optional) Should return an array of arbitrary length in the following format: