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.


 * - 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 headere. 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:
 * - TODO
 * - Should return an array of . The URL may be a relative one, and the link text should not be escaped yet. As of writing, the link text is not used anywhere yet?
 * - (Optional) Should return an array in the format of . 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.